OpenSSL Digital Certificates: Vulnerability Assessment and Solutions

This report provides a comprehensive analysis of OpenSSL and its use in generating digital certificates, focusing on security vulnerabilities and potential solutions. It begins with an introduction to OpenSSL, highlighting its features and licensing, and then reviews several vulnerabilities discovered over the years, including RSA key problems, ASN.1 sequence issues, OCSP stapling, BIO vulnerability, private key prediction, the Heartbleed bug, and CCS vulnerability. The report then discusses methods for addressing these vulnerabilities, such as Vulnerability Assessment Management (VAM), updating OpenSSL versions, overriding communication channels, using the Engine Interface, and examining the architecture. The report includes experiment results on cryptography technology for security with steps and figures on how to generate a certificate using OpenSSL. It also touches upon SSL handshake process, encryption, and key-encryption algorithms, concluding with the importance of addressing these vulnerabilities to maintain secure online services. Desklib offers this and many other solved assignments.

Assignment 3
Using OpenSSL to Generate Digital Certificates
Table of Contents
1

Introduction:-.............................................................................................................................3
Review work:-.............................................................................................................................5
Method of Solution:-..................................................................................................................7
Some more methods for the rectification of Vulnerability:-.................................................7
Using the Engine Interface:-...................................................................................................8
Experiment results with Cryptography technology for security................................................8
Now let us take a look at the SSL handshake and how it is done:-.....................................12
How does the encryption process works in SSL communication:-......................................12
How SSL uses both the methods simultaneously?..............................................................14
Key-Encryption Algorithm:-..................................................................................................14
Conclusion:-..............................................................................................................................16
References................................................................................................................................17
List of figure
Figure 1 Engine interface...........................................................................................................8
Figure 2 Generate OpenSSL.......................................................................................................9
Figure 3 Create Key..................................................................................................................10
Figure 4 key..............................................................................................................................11
Figure 5 Public key exchange...................................................................................................13
Figure 6 Encrypt-Decrypt.........................................................................................................13
2

Introduction:-
SSL stands for Secure Socket Layer and OpenSSL is a cryptography library that provides open
source implementation to the SSL layer and Transport Layer Security Protocols. OpenSSL is
licensed under Apache Style license which means one can freely use it for commercial and
non-commercial purposes depending upon the license requirement. As discussed above SSL
is a kind of library, so just like any other library SSL is also supposed to contain one or the
other different types of features. The SSL library includes:-
1. Tools for generating RSA Private Keys.
2. Tools for generating Certificate Signing Requests (CSR’s).
3. Checksums.
4. And they manage Encryption and Decryption of the site.
Commonly the SSL code is written in C language but its wrappers are available in a variety of
other programming languages. From a recent web survey it is evident that SSL is used by
almost 66% of all the web servers. OpenSSL was introduced in 1998, since then it has
involved over various versions. The most recent version of OpenSSL includes version 1.0.1f
which apparently had a bug in the code, and that bug was known as the heart bleed bug,
the bug releases 64kb of memory and it has affected around half a million secure web
servers around the globe. This problem was soon revised and a new version 1.0.1G was
devised which fixed the problem of heart bleed bug (Everhart, 2017).
Let us talk about the licensing of the OpenSSL. Now, OpenSSL is based on two license,
one is apache 1.0 and other is SSLeay license, this means that OpenSSL obeys the terms and
conditions of both these license. As written above, the OpenSSL uses apache 1.0 license
rather than 2.0 it means that whenever there is a need to advertise anything related to
OpenSSL a disclaimer has to be given in the exact format as "this product includes software
developed by the OpenSSL Project for use in the OpenSSL Toolkit”. Because of this restriction
the OpenSSL is incompatible with the general public license or GPL. But in spite of this there
are some software developers that work under the freedom of GPL and have made some
changes in their SSL document which allows them to do it (Xia, 2016). Seeing all the
inconvenience and the compatibility issue with the OpenSSL and apache 1.0 the company
3

announced in 2015 that it’ll use apache 2.0 and this announcement got implemented in
2017. Let’s have a look at the uses of OpenSSL:-
1. OpenSSL connects our system to the HTTP services.
2. OpenSSL can be used to generate random number or strings by using the keyword
‘rand’.
3. OpenSSL can verify an online certificate using the command line, which is helpful in
authenticating a server.
4. OpenSSL can be used to extract important information for the certificate.
5. OpenSSL has the capability of generating a MD5 hash.
6. OpenSSL includes a feature which lets us benchmark our system.
7. With OpenSSL we can also benchmark remote system/connections.
Seeing the above points and all the discussions it is evident that OpenSSL is extremely useful
and has a variety of uses when it comes to online services (Hao, 2014).
4

Review work:-
OpenSSL sounds great and helpful when it comes to the web servers and online services but
when reviewed closely and looking at the history of the thing there are a variety of bugs and
problems which compromised the OpenSSL over a period of time. Let us take a look at the
vulnerabilities that OpenSSL underwent over the years:-
1. Problem with the RSA keys:-
In 2003 there was a kind of timing attack on the RSA keys of openSSL toolkit. It was
discovered as a vulnerability in the SSL version 0.9.7a and 0.9.6. What happened exactly
was, there is type of visibility mode in SSL for the RSA keys which is always turned off so that
no one can see neither retrieve the RSA key of a web server. But in 2003 during the above
mentioned versions of openSSL the by default visibility mode was turned on which is not
possible while using SSL and TSL protocols using openSSL. During that time almost all the
apache clients using the openSSL were affected and it made it possible for the attackers to
obtain the private keys of the web servers (Bos, 2015).
2. Denial of ASN.1 sequences:-
RSA keys were not the only problem which was encountered by the OpenSSL in 2003. In
the same year OpenSSL experienced another bug which made the ASN.1 sequence trigger
large number of recursions on windows systems, since windows cannot handle such large
no. of recursion so as a result the OpenSSL would crash. This made all the windows systems
using OpenSSL to crash and experience the problem until a solution was devised in a new
version of OpenSSL (Thirumalai, 2016).
3. OCSP Stapling:-
What is meant by OCSP stapling? There is a always a possibility that the client, during the
handshaking process, might send an incorrectly formatted hello message, this mistake leads
the openSSL parsing to go beyond the end of the message format. This glitch/mistake can
possibly allow the attackers to read the memory segments which are contained after the
client hello message (Sjostrom, 2017).
5

4. BIO Vulnerability:-
What does BIO stands for? BIO stands for Basic Input Output. While using basic input
output functions and using ASN.1 file based functions, the OpenSSL is vulnerable, meaning it
is prone to attackers getting the information about the servers and accessing the memory
segments.
5. Private Key’s Prediction:-
OpenSSL’s pseudo random number generator uses complex algorithmic programming
also known as poor coding practice, to generate the private keys for different web servers.
To prevent the Valgrind (a memory tracking tool) to issue any type of warning a Debian
distributor using an OpenSSL platform broke the number generator and it limited the
number of random keys to be 32000 approx. Any key generated with the broken key
generator was compromised and the data encrypted using those keys was also
compromised (Liu, 2015).
6. Heart bleed bug:-
Version 1.0.1 and version 1.0.1f experienced a severe memory bug which releases upto
64 kb memory of the application with every heartbeat of the program. This memory leak
could result into attackers accessing the sensitive data, memory segments and sometimes
the private keys of the web server. This vulnerability can also compromise the privacy and
identity of the users which might happen to use that server, because of the memory leak
attackers can access the cookies which might contain information like passwords of the user
which can result into privacy invasion (Carvalho, 2014).
7. CCS Vulnerability:-
CCS injection vulnerability is a man-in-the-middle type of vulnerability which exists in the
openSSL format. This vulnerability allows the attackers to invade and interrupt the traffic
flowing through the openSSL channels. If this vulnerability is exploited by someone correctly
then it can be used to access sensitive information regarding sever’s details.
8. The vulnerability we are gonna discuss in this point allows anyone to take up a certificate
and modify it according to one’s own wish to exploit a particular we serve or a client. This
vulnerability was experienced in the openSSL version 1.0.2 (Koide, 2017).
6

Method of Solution:-
Having so many vulnerabilities it is very alarming and a pressing issue that a toolkit as
important and as useful as openSSL should be cured and made free of all these
vulnerabilities. To get over these kinds of vulnerabilities a procedure is used which is known
as Vulnerability Assessment Management or VAM. This management technique involves:-
2. Accuracy - the assessment performed on the servers should be dead accurate or it
would result into deadly outcomes. Inaccurate VAM assessments do no good to the
servers but they act as a hollow solution to the servers, without proper and accurate
assessment it is not possible to achieve proper goals or solutions to the servers.
3. Flexibility - all the components used in VAM for the purpose of assessment should be
flexible according to the server’s need of the solution. Every problem is not same and
hence the solution too is not same for every server, therefore it is needed for the
components to be flexible in their working.
4. Ease-of-use - a proper and well implemented VAM deliver accurate and precise results
without putting in maximum efforts. It scans all the available IP’s on a large scale to
determine which vulnerability to fix first (Moderl, 2015).
*Using VAM is one of the ways to get rid of the vulnerability involved in the openSSL toolkit
accurately and timely.*
The other ways in which the vulnerabilities of openSSL could be rectified is by updating the
existing openSSL versions to the latest ones to avoid suffering from any vulnerability. For
e.g. the heart bleed bug was found in version 1.0.1f and 1.0.1 and the same bug was
rectified in the updated version which was version 1.0.1G. so in this way we can achieve the
solutions of the vulnerabilities of the openSSL toolkit.
Some more methods for the rectification of Vulnerability:-
Overriding the Communication channel in openSSL – While using openSSL it is assumed that
TCP connection are always the way to communicate with the TLS records but it is not
necessarily be true always. Sometimes it is not possible to establish a TCP connection
therefore in such case a TLS session is achieved and then different transport layer work
together to establish a TCP/IP connection on the server side. Now this method can
overcome the problem/vulnerability of BIO vulnerability problem (Markovic, 2017).
7

Using the Engine Interface:-
Engine interface details of any openSSL version are given in the header part of the code
which can be modified and accessed accordion to our wish. Modifying the engine code
might give us some relaxation and advantage over the existing vulnerabilities and help us
overcome them respectively (Zarafshani, 2016).
Looking at the Architecture – The architecture of openSSL is quite dense and consists of a
variety of layers; sometimes vulnerability could be overcome by looking at the architecture
and modifying the layers according so as to minimize the risks. The figure below gives us an
idea about the architecture of openSSL. *All the above mentioned test methods and
solutions are respective to specific problems so they might or might not work along with
each and every problem devised in the literary review of the openSSL’s vulnerabilities.*
Experiment results with Cryptography technology for security
Let us take a look at the process which involves Generation of a Certificate using openSSL:-
Step I – The first step of certificate generation involves the process of generating a Private
Key. The openSSL toolkit involves the option of generating a private key which is known as
RSA key generation, the key is 1024 bit RSA key which is prepared in triple DES format and is
8
Figure 1 Engine interface

stored under PEM format which makes it readable in ASCII format. The image below shows
us how the key is generated.
Figure 2 Generate OpenSSL
2. Step II – After the generation of a Private key the CSR certificate could be generated
with the help of the private key. After the CSR certificate is generated it could be used in
either two ways:- it could be sent further to the respective authorities like Thawte or
Verisign which will read the CSR and the check the requestor and then accordingly they’ll
sign the CSR to make it valid, and the second option is to sign it personally. During the
certificate generation there are a lot of fields which should be filled carefully. One of such
field is “CommonName” which require the name of the site or domain name, so it should be
filled properly so as to secure the server from any anomaly (Rashidi, 2017).
9

Figure 3 Create Key
3. Step III -
The next step after the CSR and private key generation is to remove the passphrase from
the key. There is problem with the triple-DES encryption we read about in the above section
regarding the private key. The encryption makes the apache driver to ask for the passphrase
to be entered every time web browser is opened up, now it is not very convenient because
there won’t be someone present at all the times to enter the passphrase; therefore it is
better to remove the passphrase from the RSA Private Key. This is to be kept in mind that
removing the passphrase shouldn’t compromise the confidentiality of the RSA private key
(Hosie, 2016).
10

Figure 4 key
5. Step IV –
Now sometimes it takes a longer duration of time for the Signing Authorities to sign the
CSR certificate, therefore there is a need to generate a personally signed CSR certificate
to avoid the error message on the screen by the server. To implement a personally
signed CSR certificate which’ll run for almost 365 days, the following code is used:-
5. Step V - The step five includes the simple task of installing the certificate and private
key in the apache driver.
6. Step VI - The second last step involves the configuration of network hosts in the apache
client.
7. Step VII -
The last step involves rebooting the Apache client and testing our personally signed CSR
certificate and the private key (Martens, 2017).
11

Now let us take a look at the SSL handshake and how it is done:-
The client says hello in the first step of the handshake. Meaning the client request for all the
information it needs.
In the next step server accepts the requests and says hello asking for some details from the
client.
In the next step the client authenticates the server by checking the certificate and the
condition of the private key.
In the next step server uses its private key to decrypt the master secret and then both
client-server generate the agreed cipher.
In the last step the client and server exchange encrypted message to ensure that in the
future also the communication will remain encrypted (Pukkawanna, 2014).
*In the above steps we have seen how the connection between the client and the server is
established now let’s take a look at how this connection is encrypted and secured from any
foreign intervention.*
How does the encryption process works in SSL communication:-
We all know that SSL is an encryption method which allows the web browser and web
server to communicate in an encrypted form. SSL allows the transfer of personal
information, credit card details, passwords, etc. to flow through the network undetected.
But how this encryption works, what makes it secure, will be discussed in this section of the
report.
There are two types of encryption methods:-
1. Asymmetric Encryption:-
Asymmetric encryption also known as public key cryptography uses two separate keys
for the purpose of encryption and decryption. The encryption key which is used is public
and anyone can use it to encrypt the data but the decrypt key that is made private so
that only the desired users can decrypt the message and no one else (Lychev, 2015).
12

The encryption and decryption keys used are usually of 2048 bits which is a lot considering
the fact that they can create keys as large as 614 digits long and a super computer would
require 14 billion years to crack a 2048 bit key.
2. Symmetric Encryption:- In symmetric encryption unlike asymmetric, only one key is
required by the sender and the receiver to encrypt and decrypt the message.
The key size in symmetric encryption is usually either 128-bit or 256-bit long. The key size
depends upon the encryption and decryption capabilities of the sender and receiver side.
Which method is stronger?
Everyone makes this mistake of thinking that the asymmetric encryption is better than the
symmetric encryption as it uses keys of larger size as compared to the small size of
symmetric encryption. It is true that it’ll take significantly a huge amount of time to decrypt
a 2048 bit key as compared to a 256 bit key but the size isn’t the only deciding factory.
Keys are large as 2048 bit increase the computational burden on the system which
eventually makes the system slower, but 256 bit keys on the other hand doesn’t require that
much of computational work.
13
Figure 5 Public key exchange
Figure 6 Encrypt-Decrypt

The deciding factor lies in the usage of the keys. Since symmetric encryption uses a single
key to both encrypt and decrypt the data, it is less secure, because, what if we have to send
our decryption key to the recipient who is somewhere halfway around the world, we’ll have
a chance of losing our data integrity. But on the other hand in asymmetric encryption as
long as we remember the private key there is no need to worry of someone gets the public
key. Therefore Asymmetric Encryption is better than symmetric encryption (Chaudhary,
2018).
How SSL uses both the methods simultaneously?
Inspite of being better than symmetry encryption the SSL uses both the methods i.e.
Asymmetric encryption and Symmetric encryption. Let’s take a look at how:-
In the first step the server sends the replica of its Asymmetric Public key.
After that the client creates a symmetric session key and encrypts that key with the help of
public key and then sends it further.
The server, on receiving the encrypted key, decrypts the key using is asymmetric private
key.
After these three steps the server and client exchange encrypted data using the symmetric
session keys on a secure channel (VanHeyningen, 2015).
*It is evident that keys are the most important part of encrypting the data and therefore it is
important to learn how they are encrypted in the first place.*
Key-Encryption Algorithm:-
The process of encrypting the key is known as public-key cryptography. Now, public-key
cryptography uses encryption algorithms such as RSA and Elliptic Curve Cryptography (ECC).
Let’s have a look at each one of them:-
 RSA: - This method is based on the assumption of factoring large integer. While
developing a key through this method it is presumed that there is no such algorithm
present that would decrypt the integer factorization. While creating public keys
through this method the product of two large prime numbers is taken and presented
while keeping the main elements secret so that no one can decrypt the public key.
This algorithm was first devised in the year 1977.
14

 ECC:- As the name suggests this method uses algebraic elliptical curves to derive
public encrypted keys. While generating the key it is assumed that discovering a
logarithmic solution for a particular point on the curve at a given point of time is
Impractical. This method was devised in 1985 but came in use around the year 2004.
The advantage of using this method is the creation of smaller keys resulting in less
computation and less complexity (Holmstrom, 2018).
15

Conclusion:-
The above reports concludes the detailed explanations of the openSSL toolkit, the
vulnerabilities involved and the future steps to be taken in removing them. It is evident from
the report that the openSSL is a useful and necessary toolkit for the encryption and security
of the data that transits through the internet on a regular basis. openSSL helps encrypt and
decrypt the data in a secured and regulated manner which make it ideal for usage in almost
every aspect of the internet services we use. The report also talks about the vulnerable side
of the openSSL, about how it failed sometime to maintain the security and integrity of some
web servers and also how it overcame them with the help of fast and precise updates. It is
seen from various instances from the past that this service cannot be blindly trusted by the
man for the security of its personal information on the web, but on the contrary it is the
only option we have as of now.
The report highlights the solutions and the in-depth approach towards the methodology and
the functioning of the openSSL which should be take care of in the coming future and it
should help it in some way. The biggest advantage SSL has as of now is having the
encryption and decryption key of sizes as big as 2048 bits which can generate upto 14 billion
combination of digits which is nearly impossible to break using the current technology
humans possess. The openSSL has been vulnerable not because of any outer attack or
disturbance but because of its self-generation of bugs and errors. VMA approach should be
a regular routine which should be taken into the consideration by the openSSL development
team to prevent themselves and their users from any further possible intervention.
Since almost everything in the contemporary world is based and runs on the world wide
web it is very essential and important to secure and think about the maintenance of the
openSSL as it is the only thing which secures our personal information from getting leaked
and used in any unwanted ways by a third party benefactor.
In the end it would be just to say that openSSL is working fine but there are some iterations
and updates required to make in more robust and better working for the coming future.
openSSL should become more robust and bug free to maintain the trust and reliability of it
numerous users.
16

References
 Bos, J.W., Costello, C., Naehrig, M. and Stebila, D., 2015, May. Post-quantum key
exchange for the TLS protocol from the ring learning with errors problem. In Security
and Privacy (SP), 2015 IEEE Symposium on (pp. 553-570). IEEE.
 Carvalho, M., DeMott, J., Ford, R. and Wheeler, D.A., 2014. Heartbleed 101. IEEE
security & privacy, 12(4), pp.63-67.
 Chaudhary, R., Jindal, A., Aujla, G.S., Kumar, N., Das, A.K. and Saxena, N., 2018.
LSCSH: Lattice-Based Secure Cryptosystem for Smart Healthcare in Smart Cities
Environment. IEEE Communications Magazine, 56(4), pp.24-32.
 Everhart, C., Wong, F., Jain, A., Singh, V., Hyer Jr, R.W. and Nagasubramaniam, B.,
NetApp Inc, 2017. Methods for facilitating secure connections for an operating
system kernel and devices thereof. U.S. Patent Application 15/152,219.
 Hao, Y., Jia, Y., Cui, B., Xin, W. and Meng, D., 2014, November. Openssl heartbleed:
Security management of implements of basic protocols. In P2P, Parallel, Grid, Cloud
and Internet Computing (3PGCIC), 2014 Ninth International Conference on (pp. 520-
524). IEEE.
 Holmström, I. and Schönström, K., 2018. Deaf lecturers’ translanguaging in a higher
education setting. A multimodal multilingual perspective. Applied Linguistics
Review, 9(1), pp.90-111.
 Hosie, P. and Pforr, C., 2016. Vulnerability Analysis and Sustainability in Tourism:
Lessons from Phuket. In Crisis Management in the Tourism Industry (pp. 111-124).
Routledge.
 Koide, M., Matsuo, A., Fukui, K., Fujimoto, T., Shimoo, S., Takamatsu, K., Kyodo, A.,
Irie, D., Tsubakimoto, Y., Isodono, K. and Sakatani, T., 2017. P3353Cholesterol crystal
depth in coronary atherosclerotic plaques: a novel index of plaque vulnerability using
optical frequency domain imaging. European Heart Journal, 38(suppl_1).
 Liu, Y., Tome, W., Zhang, L., Choffnes, D., Levin, D., Maggs, B., Mislove, A., Schulman,
A. and Wilson, C., 2015, October. An end-to-end measurement of certificate
revocation in the web's PKI. In Proceedings of the 2015 Internet Measurement
Conference (pp. 183-196). ACM.
17

 Lychev, R., Jero, S., Boldyreva, A. and Nita-Rotaru, C., 2015, May. How secure and
quick is QUIC? Provable security and performance analyses. In Security and Privacy
(SP), 2015 IEEE Symposium on (pp. 214-231). IEEE.
 Markovic, D., Carrizo, S.F., Kärcher, O., Walz, A. and David, J.N., 2017. Vulnerability of
European freshwater catchments to climate change. Global change biology, 23(9),
pp.3567-3580.
 Martens, P. and Chang, C.T. eds., 2017. The social and behavioural aspects of climate
change: Linking vulnerability, adaptation and mitigation. Routledge.
 Pukkawanna, S., Blanc, G., Garcia-Alfaro, J., Kadobayashi, Y. and Debar, H., 2014,
September. Classification of SSL servers based on their SSL handshake for automated
security assessment. In Building Analysis Datasets and Gathering Experience Returns
for Security (BADGERS), 2014 Third International Workshop on (pp. 30-39). IEEE.
 Rashidi, E., Medal, H., Gordon, J., Grala, R. and Varner, M., 2017. A maximal covering
location-based model for analyzing the vulnerability of landscapes to wildfires:
Assessing the worst-case scenario. European Journal of Operational
Research, 258(3), pp.1095-1105.
 Thirumalai, C., 2016. Review on the memory efficient RSA variants. International
Journal of Pharmacy and Technology, 8(4), pp.4907-4916.
 VanHeyningen, M.D., Aventail Llc, 2015. Encrypted record transmission. U.S. Patent
8,984,268.
 Xia, H., Pei, Q. and Xi, Y., 2016. The Analysis and Research of Freak Attack Based on
OpenSSL.
 Zarafshani, K., Sharafi, L., Azadi, H. and Van Passel, S., 2016. Vulnerability assessment
models to drought: toward a conceptual framework. Sustainability, 8(6), p.588.
18