1. Openssl Protocol Configuration
  2. Openssl Protocol Pdf
  3. What Is Secure Sockets Layer
  4. Openssl Protocol
  5. Ssl Protocol Has Been Disabled

Each SSL protocol engages cipher suites to complete the encryption process and send your data securely across the Internet. Some of these suites like the protocols above have vulnerabilities or don’t provide the needed encryption strength. These are known as “weak” ciphers. OpenSSL is an open-source implementation of the SSL and TLS protocols. It includes several code libraries and utility programs, one of which is the command-line openssl program. The openssl program is a useful tool for troubleshooting secure TCP connections to a remote server. At the time of writing, the supported protocols in recent OpenSSL releases are smtp, pop3, imap, ftp, xmpp, xmpp-server, irc, postgres, mysql, lmtp, nntp, sieve, and ldap. There is less choice with OpenSSL 1.0.2g: smtp, pop3, imap, ftp, and xmpp. Some protocols require the client to provide their names. On the Quality of protection (QoP) settings panel, select TLSv1.2 from the pull-down list in the box named Protocol. Change the protocol to TLSV1.2 5. Click Apply and Save. Configure TLSv1.2 for the DMGR & Node ssl.client.props. An SSL (Secure Sockets Layer) is the standard security protocol used to establish an encrypted connection between a server and a client. After establishing the connection SSL/TLS ensures that the data transmitted between server and client are secured and intact.

Contents

  1. About OpenSSL
  2. Practical OpenSSL Usage
  3. SSL Certificates
  4. Resources

Introduction

This guide is designed to introduce the reader to the Secure Sockets Layer (SSL) application-level protocol, and particularly the OpenSSL implementation of SSL. After a brief description of exactly what OpenSSL is, and what it is useful for, the guide will further illustrate the practical usage of OpenSSL in a client-server environment, and provide specific examples of applications which may benefit from OpenSSL. Finally, the guide will lead the user through example procedures required to use OpenSSL with the popular Apache Hyper Text Transport Protocol (HTTP) server for the purpose of serving secured web pages from your Ubuntu computer.

Target Audience

To properly implement the practical steps found in this guide, the reader should be a user of Ubuntu who is comfortable with the use of command-line applications, using the Bourne Again SHell (bash) environment, and editing system configuration files with their preferred text editor application. While previous familiarity with Server Sockets Layer (SSL), or the OpenSSL implementation in particular, is not required for this guide, if desired, the reader is advised to pursue further learning from the resources listed in the Resources section of this guide in order to broaden his/her understanding of this powerful security layer.

Openssl Protocol

About OpenSSL

Secure Sockets Layer is an application-level protocol which was developed by the Netscape Corporation for the purpose of transmitting sensitive information, such as Credit Card details, via the Internet. SSL works by using a private key to encrypt data transferred over the SSL-enabled connection, thus thwarting eavesdropping of the information. The most popular use of SSL is in conjunction with web browsing (using the HTTP protocol), but many network applications can benefit from using SSL. By convention, URLs that require an SSL connection start with https: instead of http:.

OpenSSL is a robust, commercial-grade implementation of SSL tools, and related general purpose library based upon SSLeay, developed by Eric A. Young and Tim J. Hudson. OpenSSL is available as an Open Source equivalent to commercial implementations of SSL via an Apache-style license.

About X.509

X.509 is a specification for digital certificates published by the International Telecommunications Union - Telecommunication (ITU-T). It specifies information and attributes required for the identification of a person or a computer system, and is used for secure management and distribution of digitally signed certificates across secure Internet networks. OpenSSL most commonly uses X.509 certificates.

Practical OpenSSL Usage

Installing OpenSSL Toolkit

To install the OpenSSL binary toolkit, install the following packages openssl (see InstallingSoftware).

Installing OpenSSL Library

To install the OpenSSL general-purpose library, first determine the applicable version of the library available for your Ubuntu computer with the following command issued at a terminal prompt:

apt-cache search libssl grep SSL

You should observe output from the command similar to the following:

In the above example, you would most likely want to install the current OpenSSL library, which appears in the output as libssl0.9.7 (like sudo apt-get install libssl0.9.7. Install the following packages libssl0.9.7 (see InstallingSoftware). You may also need to install ca-certificates.

Installing OpenSSL Development Library

In order to build software which requires the OpenSSL general-purpose library, you must first install the development instance of the OpenSSL library. Install the following packages libssl-dev (see InstallingSoftware). Due to OpenSSL's license being incompatible with the GPL, linking the OpenSSL library with programs covered by GPL requires an explicit linking exception for packages present in the Ubuntu Archive. (Ubuntu Technical Board decision)

Basic OpenSSL Commands

The following section of the guide presents some of the more common basic commands, and parameters to commands which are part of the OpenSSL toolkit. For additional information, read the various OpenSSL system manual pages with the man command, and refer to the information presented in the Resources section of this guide.

Determine installed OpenSSL version:

openssl version

List of available OpenSSL sub-commands:

openssl help

Get additional help information on OpenSSL sub-commands by using the openssl command followed by the sub-command, and the -h switch. For example, to get additional information on the openssl enc sub-command:

openssl -h enc

List all available cipher algorithms:

openssl ciphers -v

You may benchmark your computer's speed with OpenSSL, measuring how many bytes per second can be processed for each algorithm, and the times needed for sign/verify cycles by using the following command:

openssl speed

SSL Certificates

Openssl

The following sections of this guide will introduce the concepts involved in the generation and use of SSL certificates, both the self-signed variety, and those signed by a recognized certificate authority for use with a server application supporting SSL, and the use of X.509 certificates in client applications.

SSL Certificates for Server Use

Once you have properly generated an X.509-compliant SSL certificate, you may either elect to sign the certificate yourself, by generating a Certificate Authority (CA), or you may opt to have a globally recognized Certificate Authority sign the certificate. When the certificate is signed, it is then ready to be used with the OpenSSL toolkit, or the library to enable encrypted SSL connections to a Lightweight Directory Access Protocol, (LDAP) or Hyper Text Transport Protocol (HTTP) server, for example. This section of the guide describes the certificate generation, and signing process for both self-signed, and recognized CA-signed certificates.

Generating and Signing Self-Signed Certificates

Self-signed certificates have a major advantage in that they are completely free to use, and they may be generated, signed, and used on an as-needed basis. Self-signed certificates are great for use in closed-lab environments or for testing purposes. One of the drawbacks of using self-signed certificates, however, is that warnings will typically be issued by a user's Web browser, and other applications, upon accessing an SSL-secured server that uses a self-signed certificate. By default, client applications (e.g., Firefox) will suppress such warnings for certificates that are signed using only a globally-recognized and trusted Certificate Authority, but warnings may also be squelched by importing a server's root certificate into client applications; a relevant demonstration is shown later in this guide. Using self-signed certificates in a publicly-accessible, production environment is not recommended due to the implicit trust issues arising from these warnings, in addition to the potential confusion caused to users.

Openssl Protocol Configuration

NOTE: You must obtain a certificate signed by a recognized Certificate Authority in order to establish a commercial site, e.g., for conducting 'e-commerce'.

Provided you've installed the OpenSSL toolkit previously, or per instructions above, the generation of X.509 SSL certificates is quite simple. For self-signed certificates, you must first establish a Certificate Authority (CA) by following the steps below:

Creating the Certificate Authority

First, create an initial working environment, for example within your home directory by issuing the following command from a terminal prompt:

The above command will place you in a newly-created subdirectory of your home directory named myCA, and within this subdirectory, you should have two additional subdirectories named signedcerts and private.

Within this initial working environment, the significance of the subdirectories, and their contents is as follows:

  • ~/myCA : contains CA certificate, certificates database, generated certificates, keys, and requests

  • ~/myCA/signedcerts : contains copies of each signed certificate

  • ~/myCA/private : contains the private key

Next, create an initial certificate database in the ~/myCA subdirectory with the following command at a terminal prompt:

echo '01' > serial && touch index.txt

Now create an initial caconfig.cnf file suitable for the creation of CA certificates. Using your favorite editor, edit the file ~/myCA/caconfig.cnf, and insert the following content into the file:

IMPORTANT: Make sure to adjust the obvious site-specific details in the file, such as the two instances of /home/<username>/ under [ local_ca ] and [ req ]. Also change commonName, stateOrProvinceNamecountryName etc under [ root_ca_distinguished_name ] to personalize for your environment. For more information on the directives contained within this configuration file, use the man config command.

When you've edited the file to match your environment, save the file as ~/myCA/caconfig.cnf.

Next, you need to generate the Certificate Authority Root Certificate and Key, by issuing a few commands. First, do this:

The previous command sets an environment variable, OPENSSL_CONF, which forces the openssl tool to look for a configuration file in an alternative location (in this case, ~/myCA/caconfig.cnf).

Now, generate the CA certificate and key with the following command:

You should be prompted for a passphrase, and see output similar to this:

Do not forget the passphrase used with the command above! You'll need it every time you want to generate and sign a new server or client certificate!

The above process will create a self-signed certificate using PEM format and RSA public/private key encryption. The certificate will be valid for 1825 days. The location, and purpose of the resultant files is as follows:

  • ~/myCA/cacert.pem : CA public certificate

  • ~/myCA/private/cakey.pem : CA private key

Optional Step

Strip the certificate from all its text to keep only the -CERTIFICATE- section to create a crt

Creating a Self-Signed Server Certificate

Now that you have a Certificate Authority configured, you may use it to sign self-signed certificates. Prior to beginning the steps below, you may wish to encrypt the certificate's private key with a passphrase. The advantages of encrypting the key with a passphrase include protection of the certificate in the event it is stolen.

The certificate cannot be used with SSL-enabled applications without entering the passphrase every time the SSL-enabled application is started. This condition, while being most secure, can present a problem: If the server must be started in an unattended manner as in the case of a computer restart, then no one will be available to enter the passphrase, and subsequently the server will not start. One way to eliminate this condition involves a trade-off in security: The key may be decrypted, to remove the passphrase necessity; thus SSL-enabled applications will start automatically, without a need for you to enter a passphrase.

To actually generate a self-signed certificate for use with an SSL application, follow this process:

Create the server configuration file, by editing ~/myCA/exampleserver.cnf with your favorite text editor. Add this example content:

Be sure to change the values under server_distinguished_name especially the commonName value. The commonName value must match the host name, or CNAME for the host you wish to use the key for. If the commonName does not match the intended hostname, then host / certificate mismatch errors will appear in the client applications of clients attempting to access the server.

Once you've edited the file appropriately, save it as ~/myCA/exampleserver.cnf. Generate the server certificate, and key with the following commands:

export OPENSSL_CONF=~/myCA/exampleserver.cnf

The previous command sets an environment variable OPENSSL_CONF which forces the openssl tool to look for a configuration file in an alternative location (in this case, ~/myCA/exampleserver.cnf).

Now generate the certificate, and key:

openssl req -newkey rsa:1024 -keyout tempkey.pem -keyform PEM -out tempreq.pem -outform PEM

You should be prompted for a passphrase, and see output similar to this:

Don't forget the passphrase!

Next, you may translate the temporary private key into an unencrypted key by using the following command:

openssl rsa < tempkey.pem > server_key.pem

You should be prompted for the passphrase used above, and see the following output:

If you wish to leave the key encrypted with a passphrase, simply rename the temporary key using the following command, instead of following the step above:

mv tempkey.pem server_key.pem

Remember: If you use a server key encrypted with a passphrase, the passphrase will have to be entered each time the server application using the encrypted key is started. This means the server application will not start unless someone, or something enters the key.

Now you need to sign the server certificate with the Certificate Authority (CA) key using these commands:

export OPENSSL_CONF=~/myCA/caconfig.cnf

The previous command modifies the environment variable OPENSSL_CONF which forces the openssl tool to look for a configuration file in an alternative location (in this case, ~/myCA/caconfig.cnf to switch back to the CA configuration).

Then sign the certificate as follows:

openssl ca -in tempreq.pem -out server_crt.pem

You will be prompted for the passphrase of the CA key as created in the Certificate Authority setup from above. Enter this passphrase at the prompt, and you will then be prompted to confirm the information in the exampleserver.cnf, and finally asked to confirm signing the certificate. Output should be similar to this:

Remove the temporary certificate, and key files with the following command:

rm -f tempkey.pem && rm -f tempreq.pem

Congratulations! You now have a self-signed server application certificate, and key pair:

  • server_crt.pem : Server application certificate file

  • server_key.pem : Server application key file

Use the documentation provided with the server application you wish to use the certificate, and key for in order to properly use it. See the Configuring Apache for SSL Support section below for an example usage.

Optional Step for Certain Server Applications

Some server applications, such as the Courier IMAP mail server application require that the unencrypted private key be prepended to the server certificate. To accomplish this, simply enter the following commands:

Converting X.509 Certificates to PKCS#12 for Client Applications

If you wish to generate PKCS#12 certificates from your server's Root CA X.509 certificate for client use, you will need to use the following process on the particular server certificate, and key pair you desire to export a client certificate for:

Create a single file containing both the certificate, and key with the following command:

openssl req -x509 -nodes -days 365 -newkey rsa:1024 -keyout mycert.pem -out mycert.pem

Then, convert this certificate / key combination file into the PKCS#12 certificate with the following command:

openssl pkcs12 -export -out mycert.pfx -in mycert.pem -name 'Certificate for Whatever'

Openssl protocol number

You will be prompted for an Export password, which you may use, or just leave blank.

The resultant mycert.pfx file may now be imported into applications such as Web Browsers, and E-Mail clients. Since this certificate represents the Root CA certificate of your server, all subsequent server-level certificates signed by the CA certificate will also be automatically accepted by the client application which installs this PKCS#12 version of the certificate.

Generating Certificate for Signing by Recognized CA

In order to run a production server which will engage in commercial activity, such as 'e-commerce', it is required to generate a certificate, and have it signed by a recognized Certificate Authority (CA) such as VeriSign. The process for generating a certificate request, and obtaining a certificate signed by a recognized CA can be difficult. You must complete all requisite 'paperwork' prior to creating a certificate request, and ensure all required information is accurate.

Assuming you do not wish a passphrase-encrypted key, enter the following command to generate the private key, and certificate request:

openssl req -new -newkey rsa:1024 -nodes -keyout mykey.pem -out myreq.pem

If you already have a key you wish to use, then use the following command instead:

openssl req -new -key mykey.pem -out myreq.pem

You may wish to verify the signature, and information contained in the certificate request. Verify the signature with this command:

openssl req -in myreq.pem -noout -verify -key mykey.pem

and verify the information with this command:

openssl req -in myreq.pem -noout -text

The next steps typically involve pasting the content of the certificate request file into the CA's signup form, and awaiting the certificate. Also, you should safeguard the key file, as it will be required to use the certificate you receive from the CA.

Using PKCS#12 Certificates in Client Applications

This section of the guide explains using PKCS#12 certificates for SSL connections from the client perspective, and demonstrates the process of importing certificates into the Firefox Web Browser applications, and a couple of the more popular E-Mail clients.

Importation of a root certificate into such applications enables a trusted SSL-encrypted connection to the server from whence the certificate came, free of nagging messages about the certificate being self-signed, and so on.

Importing a Certificate into Mozilla Firefox

Importation of a PKCS#12 certificate into the Mozilla Firefox Web Browser application is very simple:

  1. From within Firefox, click Edit > Preferences

  2. Click the Advanced icon

  3. Click the View Certificates button

  4. Click the Import button

  5. Browse to the location of the certificate file, which is typically a .pfx file type

  6. Highlight the certificate file, and click the Open button

  7. You may be prompted to enter Firefox's Master Password at this point, or to set an initial Master Password. Enter the current, or net password as required, confirm it, and click OK

  8. You will then be prompted to enter the certificate's Export password. If there is no such password attached to the certificate, simply click OK, otherwise enter the password, and click OK

  9. A message will appear advising that Firefox has 'Successfully restored your security certificate(s) and private key(s)'
  10. Click OK

  11. You have successfully imported the server's client PKCS#12 certificate into Firefox

Importing a Certificate into Evolution

Importation of a PKCS#12 certificate into the Evolution E-Mail client couldn't be simpler:

  1. From within Evolution, click Edit > Preferences

  2. Click the Certificates icon

  3. Click the Import button

  4. Browse to the location of the certificate file, which is typically a .pfx file type

  5. Highlight the certificate file, and click the Open button

  6. You may be prompted to enter Evolution's certificate database password at this point, or to set an initial certificate database password. Enter the current, or new password as required, confirm it, and click OK

  7. You will then be prompted to enter the PKCS12 File Password. If there is no such password attached to the certificate, simply click OK, otherwise enter the password, and click OK

  8. You should see the certificate, and its details appear in the Your Certificates section of the Evolution Settings window

  9. Click the Close button

  10. You have successfully imported the server's client PKCS#12 certificate into Evolution

Importing a Certificate into Mozilla Thunderbird

Protocol

Importation of a PKCS#12 certificate into the Mozilla Thunderbird E-Mail client application is very simple:

  1. From within Thunderbird, click Edit > Preferences

  2. Click the Advanced icon

  3. Click the Certificates entry in the right pane

  4. Click the Manage Certificates button

  5. Click the Import button

  6. Browse to the location of the certificate file, which is typically a .pfx file type

  7. Highlight the certificate file, and click the Open button

  8. You may be prompted to enter Thunderbird's Master Password at this point, or to set an initial Master Password. Enter the current, or new password as required, confirm it, and click OK

  9. You will then be prompted to enter the certificate's Export password. If there is no such password attached to the certificate, simply click OK, otherwise enter the password, and click OK

  10. A message will appear advising that Thunderbird has 'Successfully restored your security certificate(s) and private key(s)'
  11. Click OK

  12. You have successfully imported the server's client PKCS#12 certificate into Thunderbird

Importing a Certificate into the System-Wide Certificate Authority Database

You can import a CA Certificate into the system-wide database of trusted certificate authorities. Applications that use this database will automatically trust any certificates stored here.

1. Copy your certificate to the system certificate directory. At a terminal prompt, type:

2. Edit the ca-certificates configuration file /etc/ca-certificates.conf. Add the name of the file you copied to /usr/share/ca-certificates to the top of the list just after the final '#'. For example:

Instead of manually editing this file, you can run

sudo dpkg-reconfigure ca-certificates

3. Update the CA certificates database by typing:

4. You have successfully imported your certificate into the system CA certificates database.

Configuring Apache for SSL Support

To configure Apache2 for HTTPS and generate a certificate, follow the instructions in Server Guide - HTTPD and Server Guide - Certificates.

Resources

Additional resources pertaining to OpenSSL and Secure Sockets Layer appear below.

Local System Resources

man config

System manual page for the OpenSSL library configuration files

man gendsa

System manual page for the gendsa DSA private key generator

man genrsa

System manual page for the genrsa RSA private key generator

man openssl

System manual page for the openssl command-line tool

man rand

System manual page for the rand pseudo-random byte generator utility

man x509

System manual page for the x509 certificate display and signing utility

WWW Resources

CACert, a FREE X.509 Certificate Authority

OpenSSL Website

Public Key Infrastructure (X.509) (pkix)

CategorySecurityCategorySecurityCategorySecurity

  • Protocols
  • Vulnerabilities

When analyzing the communications of a website, one of the scripts it’s used is TestSSL because it’s a fast way to test the cryptography and certificates of the site.However, in the final report the results of this script should not be used as an evidence. That’s why I want to do a summary of how to check manually SSL/TLS vulnerabilities.

SSLv2

SSLv2 have a lot of weaknesses which could a allow an attacker to decrypt an modify communications.

To check whether SSLv2 is enabled on the remote host, the following command can be used:

If SSLv2 is supported, the handshake will complete and server certificate information will be returned. Otherwise, it will return a handshake failure error.

SSLv3

It has a vulnerability called POODLE which allow decryption of communications and disclosure of session cookies if an attacker does a “padding oracle” attack against ciphers using cipher-block chaining (CBC) mode. Moreover, the only non-CBC cipher supported in SSLv3 is RC4, which is know as a cryptographically weak cipher.

To test whether a system supports SSLv3, the following OpenSSL command can be used:

If SSLv3 is supported, the handshake will complete and server certificate information will be returned and the server is vulnerable to POODLE. Otherwise, it will return a handshake failure error.

TLS > v1.0

To test whether a system supports TLS, the following OpenSSL command can be used:

If it does not connect, the server might be vulnerable because it will probably use SSLv2 or SSLv3 protocols.

The cipher suite chosen specifies a set of algorithms which the client and server will use to perform key exchange, encryption, and message authentication.A cipher suite is typically described in a format similar to this:

TLS_RSA_WITH_AES_128_CBC_SHA

where RSA is the key exchange algorithm, AES_128_CBC is the encryption cipher (AES using a 128-bit key operating in Cipher-Block Chaining mode), and SHA is the Message Authentication Code (MAC) algorithm.

The cipher suites a server is configured to support should be dictated by its security requirements. The following guidelines are generally recommended as a baseline:

There are two ways to test the ciphers. The first one is with openSSL:

If some of the ciphers succeed, the server has weak ciphers.

The second option is to use Nmap, however the results should be checked with manually:

It can be seen the cipher order of the protocols available. If Diffie-Hellman is used as a key exchange, the key should be => 2048 bits

Server certificates enable the client to verify that it is connecting to the correct host. Though not usually used for HTTPS, SSL/TLS can also support mutual authentication in which the client proves its own identity through the provision of its own certificate.

To view the details of a server’s certificate, the following command can be used:

The following attributes should be checked: * Common Name, Subject Alt Name and Issuer are congruent * The chain of trust is trusted * The certificate is not self-signed * The signature algorithm is strong * The server key size is >= 2048 bits * The certificate is not expired

Heartbleed

(CVE-2009-3555)During communication, OpenSSL uses a “heartbeat” message that echoes back data to verify that it was received correctly. The problem is, in OpenSSL 1.0.1 to 1.0.1f, an attacker can trick OpenSSL by sending a single byte of information but telling the server that it sent up to 64K bytes of data that needs to be checked and echoed back. The server will respond with random data from its memory.

The following versions of OpenSSL are vulnerable: * OpenSSL 1.0.1 through 1.0.1f (inclusive)

The following versions of OpenSSL are not vulnerable: * OpenSSL 1.0.1g * OpenSSL 1.0.0 branch * OpenSSL 0.9.8 branch

This vulnerability can be check using Nmap:

It can also be checked using the module “auxiliary/scanner/ssl/openssl_heartbleed”.

Proof of concept: https://github.com/mpgn/heartbleed-PoC

CSS

(CVE-2014-0224)The vulnerability can only be exploited if both server and client are vulnerable to this issue. In the event that one of the two is vulnerable, there is no risk of exploitation.

This issue requires an attacker to intercept and alter network traffic in real time in order to exploit the flaw. This reduces the risk that this vulnerability can be exploited but does not make it impossible, updating should be a primary remediation focus regardless of the difficulty in leveraging the exploit.

This vulnerability can be check using Nmap:

Secure Renegotiation

(CVE-2009-3555)The TLS protocol, and the SSL protocol 3.0 and possibly earlier, does not properly associate renegotiation handshakes with an existing connection, which allows man-in-the-middle attackers to insert data into HTTPS sessions, and possibly other types of sessions protected by TLS or SSL, by sending an unauthenticated request that is processed retroactively by a server in a post-renegotiation context, related to a “plaintext injection” attack.

This vulnerability can be check using OpenSSL:

If OpenSSL report “Secure Renegotiation IS NOT supported”, the server is vulnerable.

Secure Client-Initiated Renegotiation DoS

When a new SSL connection is being negotiated, the server will typically spend significantly more CPU resources than the client. Thus, if you are requesting many new SSL connections per second, you may end up using all of the server’s CPU.

This vulnerability can be check using OpenSSL:

When the connection has started if pressing ‘R’ the renegotiation succeeds (HTTP response returned), the server is vulnerable.

CRIME

(CVE-2012-4929)The Compression Ratio Info-leak Made Easy (CRIME) attack is a side-channel attack against TLS compression. To carry out the attack, the attacker needs to exert partial control over the content of requests made by the client (e.g. by using a Cross-Site Scripting vulnerability to force the user’s browser to issue requests). The attacker can then observe the compressed size of these requests on the network and from that infer the contents of the remainder of the request (e.g. session cookies) based on the level of compression achieved.

This vulnerability can be check using OpenSSL:

On the servers supporting compression, a response similar to the one below will be received, containing details about the compression. The lines “Compression: zlib compression” and “Compression: 1 (zlib compression)” indicate that the remote server is vulnerable to the CRIME attack. Otherwise, the “Compression: NONE” shows that this server rejects usage of TLS-level compression.

BREACH

(CVE-2013-3587)The BREACH attack is analogous to the CRIME attack, but this time exploits the use of HTTP compression to again infer the contents of attacker-influenced requests.

This vulnerability can be check using OpenSSL:

Submitting the following will allow us to see if HTTP compression is supported by the server:

If the response contains encoded data, it indicates that HTTP compression is supported; therefore the remote host is vulnerable.Otherwise, the server will respond with uncompressed data, indicating that it is not vulnerable.

POODLE

(CVE-2013-3587)Under certain conditions, it is possible to conduct a “padding oracle” attack against ciphers using cipher-block chaining (CBC) mode. This may allow decryption of communications and disclosure of session cookies.

If the server supports SSLv3 is vulnerable to POODLE attack.

TLS_FALLBACK_SCSV

(RFC 7507)TLS agents should negotiate the highest version of the protocol supported by client and server. Clients advertise the highest version of the protocol they support. The server selects the highest version it supports, and sends the negotiated version number in the ServerHello message.

Many broken TLS implementations in widespread use were unable to cope with versions they did not understand. This caused large numbers of TLS sessions to break during the TLS 1.1 rollout and allow attackers to attack older SSL versions.

FREAK

(CVE-2015-0204)It allows an attacker to intercept HTTPS connections between vulnerable clients and servers and force them to use weakened encryption, which the attacker can break to steal or manipulate sensitive data. This site is dedicated to tracking the impact of the attack and helping users test whether they’re vulnerable.

This vulnerability can be check using OpenSSL:

If some of the server allow EXPORT ciphers, it is vulnerable.

DROWN

(CVE-2016-0703)DROWN allows attackers to break the encryption and read or steal sensitive communications, including passwords, credit card numbers, trade secrets, or financial data.

This vulnerability can be check using OpenSSL:

If SSLv2 is supported, the server is vulnerable.

LOGJAM

(CVE-2015-4000)The Logjam attack allows a man-in-the-middle attacker to downgrade vulnerable TLS connections to 512-bit export-grade cryptography. This allows the attacker to read and modify any data passed over the connection. The attack is reminiscent of the FREAK attack, but is due to a flaw in the TLS protocol rather than an implementation vulnerability, and attacks a Diffie-Hellman key exchange rather than an RSA key exchange. The attack affects any server that supports DHE_EXPORT ciphers

This vulnerability can be check using OpenSSL:

If some of the server allow EXPORT ciphers, it is vulnerable.

BEAST

(CVE-2011-3389)This vulnerability is an attack against the confidentiality of a HTTPS connection in a negligible amount of time. That is, it provides a way to extract the unencrypted plaintext from an encrypted session.Certain configurations on TLS 1.0 encrypts data by using cipher block chaining (CBC) mode with chained initialization vectors, which allows man-in-the-middle attackers to obtain plaintext HTTP headers via a blockwise chosen-boundary attack (BCBA) on an HTTPs session.

There are two things to check. It uses sslv3 or tls1 and CBC cipher:

If the server allows SSLv3 or TLS1 and it is using ciphers with CBC, then the server is vulnerable to BEAST attack.

Openssl Protocol Pdf

RC4

RC4 attacks exposes weaknesses of RC4 encryption algorithm. More precisely, in most situations where RC4 is used, these weaknesses can be used to reveal information which was previously thought to be safely encrypted.

This vulnerability can be check using OpenSSL:

If it connects, the server is vulnerable.

Lucky13

(CVE-2013-0169)The Lucky Thirteen attack is a cryptographic timing attack against implementations of the Transport Layer Security (TLS) protocol that use the CBC cipher suite against TLS connections that does not properly consider timing side-channel attacks on a MAC check requirement during the processing of malformed padding, which allows remote attackers to conduct distinguishing attacks and plaintext-recovery attacks.

This vulnerability can be check using OpenSSL:

If the server supports CBC3 ciphers, it is vulnerable.

What Is Secure Sockets Layer

Sweet32

(CVE-2016–2183 and CVE-2016–6329)The use of small block sizes (64 bits) in conjunction with the CBC (cipher block chain) operation mode, such as Triple-DES and Blowfish, allows an attacker to decrypt traffic between the server and its clients. These algorithms are commonly used in several applications and protocols such as VPN, SSH, SSL and IPSec. To perform this attack, it is necessary being able to generate and capture high amounts of network traffic (typically around 78GB).

Openssl Protocol

This vulnerability can be check using OpenSSL:

Ssl Protocol Has Been Disabled

If the server supports 3DES or Blowfish, it is vulnerable.

Coments are closed

Most Viewed Posts

  • International Space Agency
  • Amazon Prime Starz Subscription
  • Tableau Prep Free
  • Invoice Bill
  • Buildbox App

Scroll to top