OPENSSL
Create a simple HTTPS server with OPENSSL S_SERVER
This post will mostly serve as a reference for future posts, the goal is to create the simplest HTTPS webserver possible, which will serve to test certificates, authentication via private keys and in the end; configure SSL offloading to an Apache HTTPD, which will act as a proxy between your client and the secure endpoint.
GOAL: At the end of this article, you will have a running secure web server which you can access via your web browser and/or via an SSL client.
Preparation
First we need to do a bit of preparation, we need to create two certificates which will be used by the OpenSSL s_server command.
Note; You’ll only need to run this command once
joris@beanie ~
$ openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days 365 -nodes
Fill in the details of your brand new certificate.
(Explanation of the arguments can be found at the bottom of this post)
Starting the OpenSSL s_server
joris@beanie ~
$ openssl s_server -key key.pem -cert cert.pem -accept 44330 -www
Using default temp DH parameters
ACCEPT
(Explanation of the arguments can be found at the bottom of this post)
Right now, we’ve got a running secure server on port 44330
Accessing the s_server via web browser
We can test our openssl s_server by accessing the following URL via your web browser:
If everything went right, you’ll see a privacy error, this is because we’re using a self-signed certificate (created in the preparation)
After you continued past the privacy error, you’ll see the response from the openssl s_server internal webserver:
Accessing the s_server via openssl s_client
To create a full circle, we’ll make sure our s_server is actually working by accessing it via openssl s_client:
joris@beanie ~
$ openssl s_client -connect localhost:44330
CONNECTED(00000003)
depth=0 C = NL, ST = Utrecht, L = Utrecht, O = Company, OU = Unit, CN = localhos t
verify error:num=18:self signed certificate
verify return:1
depth=0 C = NL, ST = Utrecht, L = Utrecht, O = Company, OU = Unit, CN = localhos t
verify return:1
---
Certificate chain
0 s:/C=NL/ST=Utrecht/L=Utrecht/O=Company/OU=Unit/CN=localhost
i:/C=NL/ST=Utrecht/L=Utrecht/O=Company/OU=Unit/CN=localhost
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIDnzCCAoegAwIBAgIJAJXhQQyaDaR9MA0GCSqGSIb3DQEBCwUAMGYxCzAJBgNV
BAYTAk5MMRAwDgYDVQQIDAdVdHJlY2h0MRAwDgYDVQQHDAdVdHJlY2h0MRAwDgYD
VQQKDAdDb21wYW55MQ0wCwYDVQQLDARVbml0MRIwEAYDVQQDDAlsb2NhbGhvc3Qw
HhcNMTUwNzIyMDgxMDExWhcNMTYwNzIxMDgxMDExWjBmMQswCQYDVQQGEwJOTDEQ
MA4GA1UECAwHVXRyZWNodDEQMA4GA1UEBwwHVXRyZWNodDEQMA4GA1UECgwHQ29t
cGFueTENMAsGA1UECwwEVW5pdDESMBAGA1UEAwwJbG9jYWxob3N0MIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAz0wheYcT5/cDQLyXgbri/HLtu5EfmW5+
f2sF/W3rsoVftbZMpKo9bAtbuWvST/Ds5jUh3uvbBOJhoyC8Q0nh+8JxWMRW4miE
eHjodKNn951el+ME3nQJa79GfjJMMZRUqC6kxgsUS1MFoJ8NfpCpXSWf7zrbp116
6rTd2iEEUEbR1om7+DYKe5WCDThXAR7BBtKbBmKjygsWQI/QfY5zHX89SsunXxkm
TxsSVNoxBgAfeeAntK3LvHizqc0RGM1C4Dws6/wgdBum9eNZX9b7JttMpScpsJO/
vuahTG2haEENFrdsiB4FSOjg7fY+ePRs38LIUJjiSrjRSzivPlNqaQIDAQABo1Aw
TjAdBgNVHQ4EFgQU0iARW0OTZ/Z393oFcPpuAJv9qUwwHwYDVR0jBBgwFoAU0iAR
W0OTZ/Z393oFcPpuAJv9qUwwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQsFAAOC
AQEAT7cdHVM/1w2AexF02N2MmR49lE5DYkhPAhjnAnVNXzW9mk+qgn96giav12Uo
K/PMk32IrWCgnn5Rtqcm4DDLkq+4nP4/178umEMAl3JIdGbWD1Bp2qFPFSUB5+Oh
u+YIbUEiD/ahJxPhUwku8tfgnYQSw8Gie7C8O2AuOJbK+exw8WD96Bg8//Q9zvez
/hX00Xm0xu6HsVvlW4Uk434Ll8fqR0xtk/V8QeBT1YYoU7V0VB5lvHgfTOPWzwn9
15CvHz6IBfzTOnTfkRTPPTnZofyXdnIiDwV9AF/CctLp7ievwJ7AkyktWShidIrP
N7G2ypiLAsN9PPuTvJuju45fYQ==
-----END CERTIFICATE-----
subject=/C=NL/ST=Utrecht/L=Utrecht/O=Company/OU=Unit/CN=localhost
issuer=/C=NL/ST=Utrecht/L=Utrecht/O=Company/OU=Unit/CN=localhost
---
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 1598 bytes and written 481 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: zlib compression
Expansion: zlib compression
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
Session-ID: 650699D3308814F24A6F509AD74978103D7CB9D9C5E03F0EAEEC46B9D58ECA8B
Session-ID-ctx:
Master-Key: 84421FF2D9EF1855C050367A304D37030D11D9C6071C9F5FB2B7FECFE38FCC8B 4C9D5FE42C1BF530FD79CFA41A416B40
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
0000 - 46 f4 7a 4f bb 9c 77 a7-dc 8e 2a 0e d8 0a f0 a9 F.zO..w...*.....
0010 - 72 85 d1 64 9a 1d 25 7d-20 fc ab 58 fc e3 d4 05 r..d..%} ..X....
0020 - 95 dc b0 77 75 35 00 08-e8 2b 26 a2 24 28 18 0c ...wu5...+&.$(..
0030 - 6d 1d e4 8a 52 bb ce 15-04 c6 5a e2 2b f1 64 3d m...R.....Z.+.d=
0040 - 0d cf 31 6e 1d 6e 5e 7c-31 42 24 81 b8 87 b8 d0 ..1n.n^|1B$.....
0050 - 30 46 e4 9a 60 ca e6 99-9b 64 a2 4f 81 8f 66 40 0F..`....d.O..f@
0060 - 7e d2 7d 86 70 32 5c 6d-25 dd f8 00 21 6b b4 eb ~.}.p2\m%...!k..
0070 - 3f 03 32 a3 b6 cc bd a8-31 25 5b 96 1d aa ab a6 ?.2.....1%[.....
0080 - ef 15 f5 4f bd 82 e1 b7-7b cb 47 5b 39 56 94 84 ...O....{.G[9V..
0090 - e0 e3 df 4f 76 3d 8c d1-f0 43 75 88 db fe 91 6e ...Ov=...Cu....n
Compression: 1 (zlib compression)
Start Time: 1437553463
Timeout : 300 (sec)
Verify return code: 18 (self signed certificate)
—
Start Time: 1437553463
Timeout : 300 (sec)
Verify return code: 18 (self signed certificate)
—
joris@beanie ~
$
$
Explanation of the openssl req command
openssl (OpenSSL command)
req
PKCS#10 certificate request and certificate generating utility.
-x509
this option outputs a self signed certificate instead of a certificate request. This is typically used to generate a test certificate or a self signed root CA. The extensions added to the certificate (if any) are specified in the configuration file. Unless specified using the set_serial option, a large random number will be used for the serial number.
-newkey rsa:2048
this option creates a new certificate request and a new private key. The argument takes one of several forms. rsa:nbits, where nbits is the number of bits, generates an RSA key nbits in size. If nbits is omitted, i.e. -newkey rsa specified, the default key size, specified in the configuration file is used.
-keyout key.pem
this gives the filename to write the newly created private key to. If this option is not specified then the filename present in the configuration file is used.
-out cert.pem
This specifies the output filename to write to or standard output by default.
-days 365
when the -x509 option is being used this specifies the number of days to certify the certificate for. The default is 30 days.
-nodes
if this option is specified then if a private key is created it will not be encrypted.
Explanation of the openssl s_server command
openssl
s_server
The s_server command implements a generic SSL/TLS server which listens for connections on a given port using SSL/TLS.
-key key.pem
The private key to use. If not specified then the certificate file will be used.
-cert cert.pem
The certificate to use, most servers cipher suites require the use of a certificate and some require a certificate with a certain public key type: for example the DSS cipher suites require a certificate containing a DSS (DSA) key. If not specified then the filename "server.pem" will be used.
-accept 44330
the TCP port to listen on for connections. If not specified 4433 is used.
-www
sends a status message back to the client when it connects. This includes lots of information about the ciphers used and various session parameters. The output is in HTML format so this option will normally be used with a web browser.
Sources
- https://www.openssl.org/docs/apps/req.html
- https://www.openssl.org/docs/apps/s_server.html
- https://www.openssl.org/docs/apps/s_client.html
courtesy:https://blog.jorisvisscher. com/2015/07/22/create-a- simple-https-server-with- openssl-s_server/
SSL server client programming using openssl in c
The Internet is like a sea, it’s open a lot of opportunity for the new world. There are a lot of company, which depends on the internet. The Internet reduces the workload and time of the people.
Now day’s people do not use the conventional way to send the information from one place to another place but using the internet they are sending the information.Previously people used the cash money for purchasing but nowadays they are using the internet for the purchasing.
So to making all the thing secure which are transferring over the network, introduce a protocol SSL/TLS. It creates a secure connection between the client and server.
What is SSL?
An SSL (Secure Sockets Layer) is the standard security protocol used to establish an encrypted connection between a server and a client. After the establish the connection SSL/TLS ensures that the data transmitted between server and client are secured and intact.
SSL is used by many application and banking website to make the data private and secure. It provides the security in the transmission of sensitive data like credit/debit card number, user login name, and password.
Note: A Good book for SSL/TLS , Implementing SSL / TLS Using Cryptography and PKI
Working of SSL
SSL is designed to exchange the sensitive data over the network using some secure algorithms and prevent from another program that wants to access the private data from the network connection.
SSL uses asymmetric encryption algorithms to secure the transmission of data. These algorithms use the pair of keys (public and private). The public key is freely available and known for anybody. The private key is only known by the server or the client.In SSL data encrypted by the public key can only decrypt by the private key and the data encrypted by the private key can only decrypt by the public key.
In the SSL communication, the client starts the connection from the first hello (SSL) message.This hello message starts the negotiation and performs the handshaking between server and client. After the completing the handshaking if the everything is fine then generate a secured key for the current connection.Server and client have used this secret key in data exchanging.
SSL handshake flow
The SSL handshake is an authentication process. In which server and client authenticate to each other using a certificate.
This certificate is generated by the user own self with the help of OpenSSL commands or it is provided by a third party (certificate authority).
This certificate is generated by the user own self with the help of OpenSSL commands or it is provided by a third party (certificate authority).
Below I am describing some steps which described the handshaking between the server and client.
- In the beginning of the communication, SSL/TLS client sends a “client_hello” message to the server. This message contains all the cryptographic information which is supported by the client, like highest protocol version of SSL/TLS, encryption algorithm lists (in the client’s order of preference), data compression method, resume session identifier and randomly generated data (which will be used in symmetric key generation).
- The SSL/TLS server responds with a “server_hello” message to give all the things which are required to establish a connection like protocol version used, data compression algorithms and encryption method selected, assigned session id and random data (which will be used in symmetric key generation).
- The server sends a certificate to the client and also insert a request message for the client certificate because server required the client certificate for the mutual authentication.
- The SSL or TLS client verifies the server’s digital certificate. For more information, see How SSL and TLS provide identification, authentication, confidentiality, and integrity.
- If the SSL or TLS server sent a “client certificate request”, the client sends a random byte string encrypted with the client’s private key, together with the client’s digital certificate, or a “no digital certificate alert”. This alert is only a warning, but with some implementations, the handshake fails if client authentication is mandatory.
- The SSL or TLS client sends the randomly generated data that enables both the client and the server to compute the secret key to be used for encrypting subsequent message data. The randomly generated data itself is encrypted with the server’s public key.
- The SSL or TLS server verifies the client’s certificate.
- The SSL or TLS client sends the server a “finished” message, which is encrypted with the secret key, indicating that the client part of the handshake is complete.
- The SSL or TLS server sends the client a “finished” message, which is encrypted with the secret key, indicating that the server part of the handshake is complete.
- For the duration of the SSL or TLS session, the server and client can now exchange messages that are symmetrically encrypted with the shared secret key.
Example of secure server-client program using OpenSSL in C
In this example code, we will create a secure connection between client and server using the TLS1.2 protocol. In this communication, the client sends an XML request to the server which contains the username and password.
The server verifies the XML request, if it is valid then it sends a proper XML response to the client either give a message of Invalid Request.
Install the OpenSSL library, for the ubuntu use the below command.
sudo apt-get install libssl–dev
Before compiling the client and server program you will need a Certificate. You can generate your own certificate using the below command.
openssl req -x509 -nodes -days 365 -newkey rsa:1024 -keyout mycert.pem -out mycert.pem
Note: Here certificate name is mycert.pem.
Example Client code for TLS1.2 communication
Compile the Client : gcc -Wall -o client Client.c -L/usr/lib -lssl -lcrypto
Run : ./client <host_name> <port_number>
Run : ./client <host_name> <port_number>
Example Server code for TLS1.2 communication
Compile the Server : gcc -Wall -o server Server.c -L/usr/lib -lssl -lcrypto
Run : sudo ./server <portnum>
Run : sudo ./server <portnum>
How to run client server program?
Server run first, using the below command we will run the server and wait for the client request.
sudo ./server 8081
Note: In above command 8081 is the port number.
After that, we will run client using the below command and send the XML request.
./client 127.0.0.1 8081
Note: In above command, 127.0.0.1 is the local host IP and 8081 is the port number.
If the client sends a valid request as per the server then server give a proper response.
Server Response:
If the client sends an invalid request to the server then server give a response to an “Invalid message”.
Server Response:
“Invalid Message”
courtesy:https://aticleworld.com/ssl-server-client-using-openssl-in-c/
Comments
Post a Comment