Table of contents

1 Context of the project 11

1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.2 Organism welcome.......................... 11
1.3 Problematic12
1.4 Work to do12
1.4.1 Critères acceptability12
1.4.2 Acteurs 12
1.4.3 Needs fonctionnels 13
1.4.4 Needs non-functional 13
1.4.5 Constraints 13
1.5 Organization of the report 13

2 State of art 14
2.1 Introduction .............. 14
2.2 Protocols SSL/TLS14
2.2.1 Definition 14
2.2.2 History SSL/TLS15
[Link] History of the SSL protocol ...
[Link] History of the TLS protocol . . . . . . . . . . . 15
2.2.3 SSL/TLS Handshake16
2.3 Configuration HTTPS under Apache 2.................. 19
2.4 Conclusion 19

3 Audit SSL/TLS 20
3.1 Introduction 20
3.2 Audit SSL/TLS20
3.3 Study similar tools . . . . . . . . . . . . . . . . . . . . . . 21
3.3.1 Study client scan tools 21
3.3.2 Study server scan tools . . . . . . . . . . . . . . . . 22
3.3.3 Study client/server scan tools 23
3.4 Choice of the solution 24
3.5 Conclusion...

1
4 Solution proposed 25
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.2 Presentation of the proposed solution 25
4.2.1 Scan server side 25
[Link] SSLyze 26
[Link] Improvement of the SSLyze Project26
4.2.2 Scan client side28
[Link] Configuration of the SSLhaf module. . . . . . . . . 28
[Link] The default log content29
4.3 Solution Complete AliveSSL29
4.3.1 AliveSSL scan Client 30
4.3.2 AliveSSL scan Server 31
4.3.3 Choice of the server type 31
[Link] Server web31
[Link] Server FTP32
[Link] Server SMTP32
[Link] Server POP332
[Link] Server LDAP33
[Link] Choice the type of the scan 33
[Link] Result the scan. . . . . . . . . . . . . . . . . . 35
4.4 Conclusion35

5 Good Onespractices 36
5.1 Introduction 36
5.2 Recommendations36
5.2.1 Utilization 2048-bit private keys 36
5.2.2 Protection private keys37
5.2.3 Assurance of sufficient coverage of the host name . . 37
5.2.4 Obtaining certificates from a certification authority
reliable38
5.2.5 Utilization solid certificate signature algorithms 39
5.3 Configuration 39
5.3.1 Utilization complete certificate chains 39
5.3.2 Utilization secure protocols 39
5.3.3 Utilization secure encryption suites . . . . . . 40
5.3.4 Selection of the best encryption suites . . . . . . . 42
5.3.5 Confidentiality persistent42
5.3.6 Utilization exchange of strong keys. . . . . . . . . 42
5.3.7 Attenuation known issues 43
5.4 Performance.
5.4.1 Avoidance too much security43
5.4.2 Resumption of usage session 43
5.4.3 Utilization optimizationWAAnd HTTP/2 44
5.4.4 Cache public content44
5.4.5 Utilization OCSP urban community 44
5.4.6 Utilization fast cryptographic primitives ... 44

2
5.5 Protocol HTTP and application security 45
5.5.1 Chiffrement of everything 45
5.5.2 Elimination mixed content 45
5.5.3 Confidence third parties 45
5.5.4 Security cookies 46
5.5.5 Compression secure HTTP ... 46
5.5.6 Deployment HTTP Strict Transport Security . . . . . 46
5.5.7 Deployment from the content security policy . . . . 47
5.5.8 Putting in cache of sensitive content 47
5.5.9 Consideration other threats47
5.6 Validation 48
5.7 Conclusion48

3
Table of figures

1 Traffic distribution quantified by service . . . . . . . . . . . . . . 9

2 Illustration HTTP vs HTTPS10

2.1 Evolution the SSL/TLS protocol through time 16

2.2 Sequence simplified SSL/TLS handshake between the client and the
server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3 Capture with the Wireshark tool of the Client Hello message sent
by Firefox presenting the 20 cryptographic suites presented
by the browser . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.4 Example of alert that an SSL/TLS client can return in case of
problem in the negotiation. 18

3.1 Test How’s MySSL 21

3.2 Test DCsec22
3.3 Test Wormly23
3.4 Test SSLabs Server23
3.5 Test SSLabs Client 24

4.1 The added certification authorities27

4.2 Scan client28
4.3 Page welcome to the AliveSSL service 29
4.4 AliveSSL scan client ...
4.5 The supported log protocols 30
4.6 The protocols used 30
4.7 Choice of the server type 31
4.8 Description from FTP 32
4.9 Operation of SMTP........................................32
4.10 Functioning of POP333
4.11 Operation from LDAP 33
4.12 Scan regular34
4.13 Scan specific34
4.14 Result the scan 35

4
Acknowledgments

It is because we have greatly appreciated all those who have listened to us.
teas, advised, criticized, and supervised that we want to share with them all our
gratitude and we want to thank them through these lines.
We first express our sincerest thanks to Mr.
Nizar Ben Neji our educational supervisor, for the encouragements, for the
the time he devoted to us and for his valuable advice.
Our thanks also go to Mr. Hamdi Mohamed for us
having welcomed within the incubation center of the El Ghazala Pole as well as for
his support and advice which have always been a valuable help.
We would like to wholeheartedly thank our parents who have always supported us.
and to encourage us in this adventure and throughout our academic journey.
I extend my sincere thanks to all the professors of our department.
computer science and all the people who contributed directly or indirectly
through their words, their writings, their advice and their criticisms throughout the
Finally, we would like to express our gratitude to Mr. Mohamed.
Oueld El Hassan, our coordinator for his frequent visits to the organization
the internship and for his invaluable support.
A big thank you also to all our friends for their sincere friendship and trust.
Finally, thank you to the office colleagues for the constructive discussions
that we had and for their good humor.

5
6
Acronyms and abbreviations

ADH Anonymous Diffie-Hellman

AEAD Authenticated Encryption with Associated Data
AES Advanced Encryption Standard
BEAST Browser Exploit Against SSL/TLS
CA Certification Authority
CBC Cipher Block Chaining
CPU Central Processing Unit
CRL Certificate Revocation List
CSP Content Security Policy
DROWNDecrypting RSA with Obsolete and Weakened eNcryption
ECDHE Elliptic Curve Diffie-Hellman
ECDSA Elliptic Curve Digital Signature Algorithm
EV Extended Validation
FTP File Transfer Protocol
HSM Hardware Security Modules
HSTS HTTP Strict Transport Security
HTTP Hypertext Transfer Protocol
HTTPS Hypertext Transfer Protocol Secure
IETF Internet Engineering Task Force
LDAP Lightweight Directory Access Protocol
MITM Man In The Middle
OCSP Online Certificate Status Protocol
PCI DSS Payment Card Industry Data Security Standard
PODDLE Padding Oracle On Downgraded Legacy Encryption
POP3 Post Office ProtocolSHA1
RC4 Rivest Cipher 4
RFC Request For Comments
SHA1 Secure Hash Algorithm
SMTP Simple Mail Transfer Protocol
SSL Secure Sockets Layer
SRI Subresource Integrity
TCP Transmission Control Protocol
ICT Information and communication technologies
TLS Transport Layer Security
UDP User Datagram Protocol
VPN Virtual Private Network
WAN Wide Area Network 7
XSS Cross-site Scripting
Preface

Our project falls within the framework of obtaining the graduation diploma.
from the applied license in Computer Networks, specialty Technologies of the In-
training and Telecommunications within the Faculty of Sciences of
Bizerte (FSB). In search of a topic, Mr. Nizar Ben Neji approached us.
proposed the idea of creating a tool for auditing and evaluating SSL/TLS servers
Web, Messaging, and LDAP Directory. The tool will allow auditors to
security of evaluating Client and Server SSL/TLS solutions for development
a detailed report on the encryption schemes used and the vulnerabilities
of each supported protocol.
This project allowed us to apply our theoretical and practical knowledge.
critiques in a professional project framework. It was also an opportunity for
discover the professional world, its requirements and its needs in terms of communication
skills.

8
General introduction

Computer security continues to progress, evolving from an approach

from a passive, ad-hoc, and product-based approach to an end-to-end active approach
towards recognition and the container-content relationship. Nowadays, the four-
Service providers are working hard to ensure the safety of their clients.
and incorporate various security mechanisms as part of their offers
service. But security threats are constantly evolving, that's why
this reason that companies must equip themselves with adequate means to
to enhance their online services and continuously protect their clientele. The use of
encryption, notably the SSL/TLS protocol, will significantly improve the
security of online services as a whole. The implementation of SSL/TLS
guarantee to internet users:
The confidentiality of data sent online through encryption (which
may include credit card numbers and other information
financial and personal such as names and addresses.
The identity of the sites where this data will be deposited by
the use of electronic certificates

Figure1 – Distribution of traffic quantified by service

9
SSL/TLS is a protocol that operates at the interface of TCP sockets. Consequently-
sequence, all the application layer protocols such as HTTP, FTP, TEL-
NET, LDAP, SMTP and others can be protected by a transmission channel.
secured. In the case of HTTP or the Web, the number of secured websites
The use of SSL/TLS has increased in recent years. Recent data
coming from Google shows that more than 10% of web traffic is now encrypted by
SSL/TLS and 50% of encrypted traffic is generated by Google services (Figure
1). In Tunisia, most sites are either not secured by SSL/TLS or
representing configuration problems.
As part of our project, we will create a tool to scan the
servers and TLS clients. It allows for the development of a detailed report on the pro-
supported protocols, the encryption suites used, any vulnerabilities
as well as the security shortcomings related to SSL/TLS.
In this manuscript, chapter 1 presents the context of the project, the problem-
tique, the host organization as well as the detailed specification. In the chapter
2, we will present the SSL and TLS protocols and their versions. Chapter 3
Detail and explain the SSL/TLS audit operation as well as the currently available tools.
used. In chapter 4, the technological choice as well as the solution is presented.
proposed action. Finally, Chapter 5 includes a list of recommendations and
best practices that will help site administrators and security experts
to better configure their servers.

Operation of HTTP

(b) Operation of HTTPS

Figure 2 – Illustration HTTP vs HTTPS

10
Chapter 1

Project Context

1.1 Introduction
In this chapter, we outline the general context of the project. We present
firstly the host organization, the issue, the required work and the
adopted methodology.

1.2 Host organization

Our project was carried out at the Innovation Center of the El Technological Hub.
Ghazela, which is a business incubator and support structure
start-up creation projects. The innovation center is located at the hub
Technological El Ghazela, part of the 10 technopoles specialized in
different sectors of activities.
The innovation center started in January 2016 with about ten pro-
jets that have been selected in accordance with the center's policy and the
priority themes. Several teams are currently working at the level
from the innovation center and among them students on internship for their final project coming from
various establishments. These teams are currently working on the implementation
of prototypes. They benefited from guidance in various aspects such as
project management, the development of a business plan, the innovation process,
marketing, sales, industrial property and technological watch.
This center aims to:
Identify the right projects to assist in the creation of innovative businesses.
trices
Encourage the emergence of a new generation of creators and train
entrepreneurs to transform project-bearing technicians
business leaders
— Contribute to the strengthening of the industrial fabric within the framework of ICT
and minimize the factors of failure in business creation

11
1.3 Problematic
Nowadays, companies offer their customers the opportunity to make
financial and economic operations remotely without having to appear in person
in person. If experience has shown that this was beneficial and even very
attractive, it also presents a hyper real danger when security is not
at the meeting. To ensure the security of online services, a set
Audit tools can be used to identify potential vulnerabilities.
Most existing tools are application vulnerability scanners.
who do not perform the inspection of server-side configurations and more specifically
the SSL/TLS configuration. Even existing tools do not perform all the tests
necessary to address the issues related to this protocol. They focus solely on
comment on the server side ignoring vulnerabilities related to the part
customer and they only deal with the case of the Web and neglect other applications
SSL/TLS applications such as messaging, LDAP directories, data transfer
file and the other services.

1.4 Work to be done

Pour résoudre les problèmes suscités, nous allons développer un service web
for the SSL/TLS audit of server and client solutions to determine any potential
vulnerabilities related to the protocols and encryption suites used and
to generate a detailed report on the issues encountered. At this level of this
project, we also present the recommendations and the relevant good practices regarding the
SSL/TLS configuration on the client and server side. The service that will be developed
is intended for listeners and security administrators and users
wanting to assess their SSL/TLS client.

1.4.1 Acceptability Criteria

The work that will be done on this project will be validated based on the
expressed needs at the level of the specifications. Our work will not be validated
what if:
Allows for a good verification of the SSL/TLS configuration side
server and client side (the certification chain, the supported protocols,
the effectiveness of encryption and key exchange
Provides a set of recommendations and best practices for
security auditors

1.4.2 Acteurs
Auditors, security administrators, and web users
will be the actors of the SSL/TLS audit service.

12
1.4.3 Functional requirements
The functional requirements of the solution are:
Scan the SSL/TLS configurations of SMTP, FTP, POP servers,
IMAP, LDAP and the others
— Scan the SSL/TLS client solutions such as browsers (IE, Chrome,
Firefox, Opera, ...), messaging clients (MS Outlook, Mozilla
Thunderbird, ...), LDAP clients and others
Develop a report on potential vulnerabilities and insufficiencies.
security
Present a set of recommendations and best practices concerning
enhancing security through the SSL/TLS protocol

1.4.4 Non-functional requirements

The developed solution meets the following non-functional requirements:
The performance and reliability: the web service must operate in the
best conditions. To achieve this, it is necessary to manage errors well and the
exceptions and manage the load in the case of multiple connections
simultaneous.
Ergonomics: the web application must have a certain clarity and
of simplicity of use.
Portability: the web application must work on various platforms.
monitoring and inspecting various client and server solutions.
Scalability: the application must be extensible and easy to maintain.
to meet future needs

1.4.5 Constraints
The solution must be low-cost and developed with open-source solutions.
The final product must be delivered to the company no later than May 31, 2017.

1.5 Organization of the report

Our report consists of five chapters. Chapter 2 details the protocol.
SSL/TLS and the detailed process for its implementation on the server side.
Chapter 3, we present the importance of the SSL/TLS audit as well as the study
comparative of existing tools. Chapter 4 presents the solution in detail.
proposed. We provide a set of recommendations in chapter 5.
and good practices to help stakeholders perform their duties properly
SSL/TLS security task. We conclude the report with the objectives.
achievements and possible future improvements.

13
Chapter 2

State of the art

2.1 Introduction
Nowadays, security plays a very important role in the field.
networks and telecommunications. E-commerce customers
do not have enough confidence to pay by credit card. To secure
for this payment, it is necessary to use authentication and encryption protocols
comme SSL/[Link] ces protocoles, les données personnelles des clients (nu-
credit card number, password, etc.) will be protected and no one can
to intercept them.
In this chapter, we will present in detail the SSL/TLS protocol, its dif-
different versions, the flaws and vulnerabilities recognized for each version
as well as the implementation of the latter on the server side.

2.2 SSL/TLS Protocols

2.2.1 Definition
SSL (Secure Sockets Layer) and TLS (Transport Layer Security) protocols
are two cryptographic security protocols allowing authentication
authentication and data encryption between two entities client and server.
TLS is the successor of SSL, the latter two operate in a mode
client/server meeting the following objectives:
server authentication as well as client authentication: SSL/TLS authentication
simple and mutual
the confidentiality of data exchanged through hybrid encryption
communications
the integrity of the exchanged data
SSL/TLS was originally designed by Netscape and is currently a standard.
officially standardized by the IETF. The SSL/TLS protocol is a security protocol
A protocol that creates a secure channel between two communicating machines on the Internet.

14
It is used to secure authentication and electronic transactions.
The two protocols SSL and TLS operate between the transport layer (TCP)
or UDP) and the application layer to natively secure protocols little
Sure. It is the most widely used security protocol today on the Internet.
allows securing multiple applications and network services such as transfer
file transfers via FTP, VPN connections, instant messaging, and voice
on IP.
The SSL/TLS protocol consists of two components: the TLS Record and
the TLS Handshake. The TLS Record aims to encrypt connections with
a symmetric algorithm and the TLS Handshake aims to authenticate both
communicating parties, to allow them to negotiate the algorithms as well
the protocol. The protocol includes the verification of electronic certificates of
client and server to ensure the identities of the communicating entities.

2.2.2 SSL/TLS History

The SSL/TLS protocol was born in 1994 and was created by Netscape. It has evolved.
Over time, given the new technological requirements and the vulnerabilities
detected as BEAST, PODDLE and DROWN (See Figure2.1)

[Link] History of the SSL Protocol

In the beginning, Netscape developed version SSL 1.0 which remained theoretical and
was never implemented. The versions that were implemented and widely
used are:
SSL 2.0 is the initial version that was developed in 1995. It pre-
has security issues and has been discouraged since then.
a long time.
Netscape developed SSL 3.0 the following year to replace SSL 2.0
which had several vulnerabilities such as DROWN and others. This
The version remained active and widely used for a good period.
Google's research team identified a vulnerability named PODDLE.
in the design of this version that allows to decrypt the content
information exchanged between the victim's web browser and the
secure server with the Man in the Middle attack. Because of POODLE,
the majority of browsers have definitively disabled SSL 3.0 around
end of 2014.

[Link] History of the TLS Protocol

TLS 1.0 was developed in 1999. The evolution of SSL led to the proto-
the TLS protocol that was entrusted by the IETF. TLS 1.0 was just a slight mention
SSL 3.0 solution which presents part of the establishment of the connection
(handshake) and brings flexibility with the introduction of extensions
optional ones that allow the protocol to evolve without revising its

15
 The major weakness is the BEAST attack, which is based on Ja-
JavaScript allows an attacker on the same network to intercept
and to decrypt SSL cookies through an attack on encrypted packets.
This version is also unable to use encryption suites.
modern ones that offer greater security and efficiency. Following these
weaknesses, this version has been replaced by a newer, safer one.
TLS 1.1 was developed in 2006, it is the second most recent version.
TLS is a transitional version that consolidates certain RFCs.
intermediaries and includes a modification of the initialization of CBC blocks
(following a report made in 2011). However, the environment of
modern security has pushed towards TLS 1.2.
TLS 1.2 is the latest version of TLS. This version allows access
to advanced encryption suites that support crypto-
elliptic curve graph (efficiency for information exchange)
on an unsecured channel). It brings a significant evolution that
present in authenticated block encryption modes AEAD.

Figure 2.1 - Evolution of the SSL/TLS protocol over time

2.2.3 SSL/TLS Handshake

The Handshake part of TLS is responsible for authentication and
the exchange of keys necessary to establish a secure session (See Figure
2.2)When establishing a secure session, the Handshake protocol
manage the following:
Negotiation of the encryption suite: The client and the server enter into
contact and choose the encryption suite that will be used throughout
from their exchange of messages.
Server authentication: the server proves its identity to the client
thanks to his electronic certificate. The client may also need
to prove one's identity to the server if necessary. The use of
Public/private key pairs are the basis of this authentication. The
The exact method used for authentication is determined according to the

16
 negotiated encryption suite.
Elaboration and exchange of a session key between the client and the server: In
first, the communicating parties agree on the algorithm
of symmetric encryption that will be used and secondly, the client
SSL/TLS generates the symmetric session key based on the choice
carried out.
This protocol aims to allow the server and the client to authenticate.
tie each other and then negotiate an encryption algorithm and a key
cryptographic before the application transmits.
As shown in the Figure2.2a first ClientHello message is sent by
the client to the server to initiate communication. In this message, the client
propose a set of cryptographic suites that it is capable of implementing
work (See Figure2.3).Each of these cryptographic suites describes the
cryptographic mechanisms that will be used for the following functions:
the exchange of keys
server authentication.
the protection of application data, in confidentiality and integrity.
This message contains other parameters that need to be negotiated: the ver-
version of the standard used (SSLv2, SSLv3, TLS 1.0, TLS 1.1 or TLS 1.2) and
the compression mechanism that will possibly be applied to the data
applicatives. In response, the server will refuse the negotiation if none of the proposals...
the client's situations are deemed acceptable. The server then ends the connection.
Otherwise, the server chooses an encryption suite from those
proposed by the client and sends the ServerHello message that states its choice
in which he presents his electronic certificate and sends a message Serve-
HelloDone to indicate that it is now waiting for a response from the client.

Figure 2.2 – Simplified sequence of the SSL/TLS handshake between the client and the
server

17
 At the end of the negotiation, once the chosen encryption suite and the cert-
Received certificate, the client verifies the certification chain and the status of the certificate.
server. If the certificate is not validated, the client issues an alert that ends
the connection (See Figure2.4).Otherwise, he continues and sends a message, Client-
KeyExchange, containing the encrypted pre-master secret. From there, the client and
the servers both have a shared secret key and several elements
random public keys exchanged during ClientHello and ServerHello messages.
These shared elements will be useful for providing the symmetric keys that will be
used to protect all sessions: to ensure confidentiality and
the integrity of exchanges. ChangeCipherSpec messages are exchanged to
indicate the activation of the negotiated parameters (algorithms and keys). The mes-
Finished sages are therefore the first to be protected cryptographically, and
contain a hash of all the messages exchanged during the negotiation
in order to guarantee retrospectively the integrity of the negotiation.

Figure 2.3 - Capture with the Wireshark tool of the Client Hello message sent
by Firefox presenting the 20 cryptographic suites presented by the browser

Figure 2.4 – Example of an alert that an SSL/TLS client may return in case of
problem in the negotiation.

18
2.3 HTTPS Configuration under Apache 2
In this section, we will talk about the configuration of the HTTPS protocol with
Apache 2 on Ubuntu 14.04.
1. Installation of the Apache SSL module so that the SSL protocol can
work with the Apache 2 server:
sudo apt-get install mod_ssl
2. Activation of the SSL module for Apache 2:
sudo a2enmod ssl
3. After activating the SSL, the web server needs to be restarted for it to take effect.
modification should be taken into account:
sudo service apache2 restart
4. Creation of the electronic certificate using the Op toolenSSL[[Link]
At this stage, we need to specify the domain name of the site that will
appear at the certificate level. The location of the SSL certificate and
The server's private key will be placed in the /etc/apache2/ssl directory.
sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout
/etc/apache2/ssl/[Link] -out /etc/apache2/ssl/[Link]
5. Configuration of VirtualHost at the Apache level:

6. Activation of the VirtualHost configuration:

sudo a2ensite [Link]
7. Starting the Apache server:
sudo service apache2 start
8. Test du serveur Web avec le navigateur Firefox :

2.4 Conclusion
In this chapter, we presented the SSL and TLS protocols as well as their
history and known vulnerabilities. We also set the SSL/TLS configuration
under Apache. The SSL/TLS configuration alone is not sufficient. It is
Why it is necessary to equip oneself with a tool for evaluating the configuration that has been made.
In the following section, we will explain and present the SSL/TLS audit.

19
Chapter 3

Audit SSL/TLS

3.1 Introduction
Cybersecurity is related to the Internet, often involving the security of
web browser and also network security. The SSL/TLS protocol intervenes
to ensure that communications between two systems do not fall into
in bad hands and that they cannot be read or manipulated.
In this chapter, we emphasize the importance of the follow-up SSL/TLS audit.
by a study on existing similar tools. And finally, we conclude this chapter.
by a justification of the choice of our solution.

3.2 Audit SSL/TLS

In the field of cybersecurity, the audit is used to make
evaluation, verification or control operations. It allows for gathering
objective information to determine to what extent the elements
An observed system must meet the requirements of a concerned domain.
In this context, we can talk about the SSL/TLS protocol which allows the establishment of
During the negotiation of a secure connection, it is during this process that the client and
the servers choose known systems (protocols, cipher suites).
During this negotiation, it is essential to verify the identity of the entity with which
a machine communicates. It is necessary to ensure that the client communicates with the
server he claims to be. In this case, the SSL certificate comes into play, it is a
a type of identity proof of a website, is also a data file that links
a cryptographic key to an individual's information. The latter is installed
on a server to ensure a secure connection between the web server and the
browser.
The use of SSL/TLS certificates is becoming widespread for:
Access to secure sites.
Banking applications.
Responses to public procurement tenders.

20
SSL certificates are issued and signed by a trusted third party (authority
of certification) to ensure the connection between two communicating entities. For
a website, it is necessary to adopt an SSL certificate for the security of visitors
website (for example, in the case of an e-commerce site). The configuration of this type of
the certificate was not always acceptable, that's why it is necessary to use
tools that allow it.

3.3 Study of similar tools

Since the use of the SSL/TLS protocol allows for secure connections...
encrypted communications which prevents data from being intercepted.
There are many assessment tools for SSL/TLS configuration, but
Has an advantage over others, there are those who scan the server.
and others that scan the client and also tools that allow scanning
both of them.

3.3.1 Study of client scan tools

This section presents tools similar to our proposed solution.
that allow scanning at the client level, such as the tool How's MySSL and
DCsec.
MySSL is a tool that scans the client (browser) allowing
to check the supported protocols and their versions
and on the supported encryption algorithms. It is designed to help a
developer of a web server to better learn about TLS clients. This
the tool has been expanded to give developers a quick and easy way
to better understand the tools used. Its main drawback is
that it does not present all the sequences of curtains.

Figure 3.1 – Test How’s MySSL

21
 DCsec is a tool created by a group of researchers that allows for evaluation.
the browser while providing the sequences of encodings and the proto-
supported schools. This tool does not provide the security level of each
suite of encoding.

Figure 3.2 - Test DCsec

3.3.2 Study of server scan tools

This section presents some tools similar to our solution.
proposed that allow scanning at the server level, such as the SSLyze tool
and Wormly.
SSLyze is an open-source project that analyzes the configuration of a server.
He is fast and understandable and helps the listeners to identify
bad configurations affecting their server. This tool is characterized
by a security test for encryption suites, validation and
verification of the revocation of a server's certificate.
Wormly is a tool that performs an in-depth analysis on the configuration.
tion and the performance of the web server including the supported protocols
and known security weaknesses. This online tool also allows to
test an SMTP mail server. Its main disadvantage is that it
does not present the encryption suites supported by the server.

22
 Figure 3.3 – Test Wormly

3.3.3 Study of client/server scanning tools

SSLLabs is a tool that provides an SSL test to verify the proper
installation of certificates as well as the SSL/TLS security of your server and
detect SSL configuration weaknesses and performance issues.
This tool is one of the most popular SSL testing tools for verifying all
the vulnerabilities and the misconfiguration of the SSL/TLS protocol. This tool
allows scanning only web servers.

Figure3.4 – Test SSLabs Server

23
 Figure3.5 – Test SSLabs Client

3.4 Choice of the solution

Following our preliminary study that allowed us to understand deeply
the concept of our topic, we found the open source project SSLyze which is
It serves as a Python library for analyzing the configuration.
SSL/TLS of a server, however this solution can still be improved. We
also found the Apache SSLhaf module which allows for packet analysis
ClientHello. Following this study, we took the initiative to design a solution.
complete that allows launching a scan at the client and server level in
exploiting these two solutions. It is noted that we chose SSLyze for its speed
scans and their automatic sending. This tool is characterized by a test of
performance and a security test, regarding the choice of SSLhaf is
justified by its ability to analyze the ClientHello packets coming from the client.

3.5 Conclusion
In this chapter, we conducted a study on the different tools similar to
our proposed solution. Although these tools include different services,
finding a comprehensive solution is still a major objective. Indeed
we briefly presented the choice of our proposed solution which will be
described in detail in the next chapter.

24
Chapter 4

Proposed solution

4.1 Introduction
A bad configuration of the SSL/TLS protocol can make it insecure.
and even vulnerable to attacks and since there are many parameters of
available configurations, it is difficult to know in advance what impact certain
Changes will occur, these changes may be made accidentally.
So in this case, you need to use a comprehensive SSL/TLS assessment tool to
the verification of the configuration and to know if the system is vulnerable. We
We will present in this chapter our proposed solution in a detailed manner.

4.2 Presentation of the proposed solution

At the level of our project, we have adapted and integrated the open-source tool SS-
Read and the Apache SSLhaf module. The components implemented will per-
to evaluate the SSL/TLS configuration and perform a complete scan on the
server/client. For this reason, our tool AliveSSL provides:
A client-side scan that provides the SSL/TLS configuration of the browser.
the suites of chiffring and the active protocols.
A server-side scan that provides the SSL/TLS configuration of the server,
the encryption suites, the supported protocols and whether it is vulnerable to
some types of attacks.

4.2.1 Server Side Scan

A large number of available encryption suites and rapid progress
in cryptanalysis makes the evaluation of an SSL server an obvious task,
from which it is necessary to choose the SSL/TLS scanning tool carefully. For these reasons,
our tool must allow for a complete scan of the installed certificates
on a server, the suites of encrypting, and to meet this need we have
used and integrated the SSLyze tool.

25
[Link] SSLyze
SSLyze is an open source Python project that analyzes SSL/TLS configuration.
of a server. It is designed to be fast and comprehensive, and should help organizations
organizations and testers to identify the bad configurations affecting their
SSL servers. To scan a server, we run this command:

[Link] Improvement of the SSLyze Project

Some improvements have been added to the SSlyze project to make it more
reliable and more efficient that are identified in this section.

The Addition of Certification Authorities Certification authorities are

a trust tier allowing the authentication of the identity of correspondents.
Each entity natively integrates a list of certificates from different
certification authorities chosen according to internal rules defined by the developers
Entity leakers (for example: Adobe), this list is in .pem format, we
has added lists to the SSLyze project to make the scan more reliable.

26
 The added lists are:
— Google CA store
— Adobe CA store
Microsoft CA store
Java CA store

Figure 4.1 - Added certification authorities

The addition of the attack test The SSL/TLS protocol indeed includes a
certain number of vulnerabilities that a malicious user can exploit
to provoke a denial of service or introduce malicious code or even
intercept the traffic between the two communicating parties.
There are several vulnerabilities in the versions of the SSL/TLS protocol.
such as the DROWN attack. However, we have added a test for this attack.
Test of the Drown attack on SSLv2: this vulnerability allows a hacker to rec-
to retrieve information from a server and to compromise a communication
using the SSLv2 protocol:

27
4.2.2 Client-side scan
The client-side scan involves analyzing the supported protocols and
the suites of differently configured on a browser. At the beginning of the commu-
In SSL/TLS communication, the client sends a ClientHello packet to the server that contains
all the browser information.

Figure 4.2 – Scan client

D’où nous avons trouvé le module SSLhaf qui permet de capturer le paquet
ClientHello and record this data in a log file.

[Link] Configuration of the SSLhaf module

In this section, we will present the steps for configuring the module
Installing SSL on Ubuntu 14.04:
Copy files from GitHub:
git clone [Link]
Compilation of the module
sudo apxs -cia mod_sslhaf.c
This script adds the LoadModule in the Apache configuration files.
– Manually adding the module in the [Link] file
This file is located in /etc/apache2/sites-enabled/; we add the lines to it.
following:
LoadModule sslhaf_module /usr/lib/apache2/modules/mod_sslhaf.so
CustomLog logs/[Link] "%t %{X-Forwarded-For}i "%{SSL-
HAF_HANDSHAKE}
%{SSLHAF_PROTOCOL}e %{SSLHAF_SUITES}e
%{SSLHAF_COMPRESSION}e
%{SSLHAF_EXTENSIONS_LEN}e %{SSL-
HAF_EXTENSIONS}e" "%{User-Agent}i"
env=SSLHAF_LOG
Opening the local server
Https://[Link]:443
Content of the [Link] file
The file [Link] located in /etc/apache2/logs/[Link] contains
now the SSL configuration of the browser visiting [Link]
.

28
[Link] The default log content
The content of the log file is incomprehensible:
The first field contains the version of the SSL protocol used: 2 and 3
for SSLv2 and SSLv3+ for example Google bot uses SSLv2 handshake
so he is ready to use SSLv2 or better.
The second field contains the best version used, for example
SSLv3 is "3.0", TLSv1.0 is "3.1", TLSv1.1 corresponds to "3.2" and TLSv1.2
corresponds to '3.3'.
The third field contains the list of differently supported sequences.
by the client.
Each sequence is associated with a hexadecimal code. For example:
0x04 represents the SSL_RSA_WITH_RC4_128_MD5 suite,
0x010080 represents SSL_CK_RC4_128_WITH_MD5
and 0x05 represents the suite SSL_RSA_WITH_RC4_128_SHA.
The fourth field contains the list of compression methods of-
provided by the client (00 = NULL, 01 = DEFLATE).
From where, we were forced to convert this content using PHP so that we could
show users a comprehensible result.

4.3 Complete Solution AliveSSL

Our web application AliveSSL allows the use of both SSLyze and
SSLhaf to perform a complete assessment of the SSL/TLS configuration side
server/client.

Figure 4.3 - Homepage of the AliveSSL service

29
4.3.1 AliveSSL scan Client
This part of our web application uses the log file generated by the mo-
dual sslhaf by changing the content to make it understandable for the audience
We extract the content of the log field by field and the third field will be
compared with a database to determine the number sequences differently
related to each hexadecimal code.

Figure4.4 – AliveSSL scan client

Then we can determine the protocols supported by the browser using the
first field of the log file.

Figure 4.5 – Supported log protocols

The protocol used can also be determined by the second field.

Figure 4.6 - The protocols used

30
4.3.2 AliveSSL scan Server
This part of the web application allows testing the server configuration.
thanks to SSLyze where we will analyze its content and display it to the auditor.
sslyze can perform scans on multiple types of servers such as LDAP,
FTP, SMTP, POP3. From where our web application will be able to perform scanning.
on these types of servers.
Our application provides auditors with an interface where they can choose
the type of server to analyze which can be a web server, SMTP, LDAP,
FTP and POP3.

4.3.3 Choice of server type

Figure 4.7 - Choice of server type

[Link] Web server

The web server is specifically a multi-service server used to
blier sites on the Internet, this type of server is a computer that stores the
files that make up a website (for example HTML documents, images,
the javascript files) and allows them to be sent to a user’s device that
visit the site. This computer is connected to the Internet and it is generally accessible
possible via a domain name such as [Link].

31
[Link] FTP Server
FTP server (File Transfer Protocol) allows the exchange of files on In-
Internet. Any authorized user can download or upload files on
a remote computer running such a server. The default port is
commonly used is port 21.

Figure 4.8 - Description of FTP

[Link] SMTP Server

The SMTP server is a communication protocol used for trans-
Sends emails to email servers.
The transfer takes place on port 25. We must start with the specification of the ex-
sender of the message then the one or more recipients of a message. It is possible
to test an SMTP server using the telnet command on port 25 of a
remote server.

Figure 4.9 - Operation of SMTP

[Link] POP3 Server

The POP3 server is a protocol for retrieving emails.
electronic devices located on a remote email server when
you are not constantly connected to the Internet. It allows you to download the
messages and remove them from the server.

32
 Figure 4.10 – Operation of POP3

[Link] LDAP Server

The LDAP server (Lightweight Directory Access Protocol) is a protocol
access to lightweight directories allowing the management of directories; to access
user information databases on a network through pro-
TCP/IP protocols. This protocol defines the method of data access on the
server at the client level, and not the way in which the information is
stored. A directory is designed to handle many more requests in
read only in writing.

Figure 4.11 - Operation of LDAP

[Link] Choice of scan type

After selecting the server type, the auditor chooses the type of scan to perform.
on this server. He can choose either a regular scan or a specific scan.

33
 Figure 4.12 - Regular scan

In the case of the regular scan, our application provides auditors with
information on the protocols supported by the server, the cipher suites
of each protocol and information about the electronic certificate(s) of the
server. Thus, if the server is vulnerable to some attacks as follows:
screen
In this case, the auditor must choose a specific scan or also on which point.
perform the scan, either on a specific protocol or on a well-defined attack
or even on the electronic certificate only.

Figure 4.13 - Specific scan

34
[Link] Scan result
After selecting the type of scan, AliveSSL displays the result according to the type of
chosen scan by presenting a report on the specific points that the auditor has
choose.

Figure 4.14 – Scan result

4.4 Conclusion
In this chapter, we have highlighted our proposed solution that we have
detailed its different steps and the improvements we have added. Following
In this phase, we take into account the misconfiguration that can generate ...
critical attacks due to a poor understanding of the SSL/TLS configuration.
That's why we provided a section dedicated to best practices in the
chapter 5.

35
Chapter 5

Best practices

5.1 Introduction
SSL/TLS is a deceptively simple technology, easy to deploy, but
His main problem is that encryption is often not easy to deploy.
correctly. To ensure that TLS provides the necessary security, the admins-
system betrayers and developers must make extra effort
to the configuration of their servers and the development of applications.
In this chapter, we will present recommendations and best practices.

5.2 Recommendations
In TLS, security begins with the cryptographic identity of the server.
a strong private key is needed to prevent attackers from carrying out
identity theft attacks. It is also important to have a valid certificate
and, solid that gives the private key the right to represent a host name
particular. Without these two fundamental elements, nothing else can be.
secured.

5.2.1 Use of 2048-bit private keys

For most websites, the security provided by 2048-bit RSA keys
bits are sufficient. The RSA public key algorithm is widely supported,
what makes keys of this type a safe default choice. At 2048 bits, these keys
provide about 112 bits of security. If we want more security than this,
It is noted that RSA keys do not scale very well. To achieve 128 bits of
security, we need 3072-bit RSA keys, which is significantly more
Lent. ECDSA keys offer an alternative that provides better security and
better performance. At 256 bits, ECDSA keys provide 128 bits of
security. A small number of old clients do not support ECDSA,
but modern clients do it. It is possible to get the best of both.

36
and to deploy RSA and ECDSA keys simultaneously if the overhead of the
managing such a configuration does not bother you.

5.2.2 Protection of private keys

Treat your private keys as an important asset, restricting access to
smallest possible group of employees while keeping your arrangements pra-
Policies recommended include the following elements:
Generate private keys on a trusted computer with entropy
sufficient. Some certification authorities allow you to generate
private keys; in this case, they should be avoided.
Assist the keys with a password from the beginning to avoid any com-
promises when they are stored in backup systems. The keys
private ones do not contribute much to production, as an attacker
well-informed can always retrieve the memory keys of the process.
There are hardware devices (called hardware security modules)
or HSMs (Hardware Security Modules) that can protect the
private keys, even in the event of server compromise, but they are expensive and
can only be justified for organizations with requirements.
strict security.
After a compromise, revoke the old certificates and generate new ones.
wants keys.
Renew the certificates every year, and more often if you can.
automate the process. Most sites should assume that a
the compromised certificate will be impossible to reliably revoke. The
certificates with a shorter lifespan are therefore more guaranteed in
practice. Unless the same keys are important for key pinning
public, you also need to generate new private keys each
time you receive a new certificate.

5.2.3 Assurance of adequate hostname coverage

Make sure that your certificates cover all the names you want.
use with a site. Your goal is to avoid certificate warnings
invalid, which confuses users and undermines their trust. Even
when you expect to use a single domain name, don't forget
that you cannot control how your users arrive on the
site or how others link it. In most cases, you need to
ensure that the certificate works with and without the www prefix (for example, it
it must work for [Link] and [Link]). The general rule
Does a secure web server need to have a valid certificate for each
DNS configured to point. Generic certificates have their uses,
but avoid using them if it involves exposing the underlying keys to
a much larger group of people, and especially if they cross the
limits of the team or such a department. In other words, the fewer there are
the more people with access to private keys, the better it will be. Also know that

37
the sharing of certificates creates a link that can be abused to transfer
vulnerabilities of a website or server to all other sites and servers
who use the same certificate (even when the underlying private keys are
different things.

5.2.4 Obtension des certificats d’une autorité de certifica-

tion fiable
Select a Certification Authority (CA: Certification Authority) that
is reliable and serious regarding its certification activity and its security.
Consider the following criteria when selecting your certification authority.
cation :
— Security position: All certification authorities are subject to
regular audits, but some are more serious regarding security
what other. Determine what are the best authorities on this aspect
which is not easy, but one option is to examine their history
of security and the most important thing is how they reacted to the
compromise and if they have learned from their mistakes.
—Busnies focus:Thebusnies cefiaortinauhtoeitsw
ri hoseacoitns-
are a substantial part of their business have everything to
lose if something is terribly wrong, and they will not neglect pro-
they are certainly not dividing their certificates by searching for opportunities
potentially more lucrative elsewhere.
— Offered services: At a minimum, your selected certification authority
should provide support for list revocation methods
certificates (CRL: Certificate Revocation List) and the status protocol
online certificate status (OCSP: Online Certificate Status Protocol), with
a reliable network availability and performance. Many sites
are satisfied with the certificates validated by the domain, but you should
also consider if you need extended validation certificates
due (EV: Extended Validation). In both cases, you should have
a choice of public key algorithm. Most websites use
RSA today, but ECDSA may become important in the future in
reason for its performance advantages.
Certificate management options: If you need a large
number of certificates and that you are in a complex environment,
choose a certification authority that will provide you with good tools
to manage them.
— Support: Choose a certification authority that will provide you with a
Good support if you need it.
Note: For better results, obtain your certificates from
in advance and at least one week before deploying them into production.
This practice helps you avoid certificate warnings for certain ones
users who do not have the correct time on their computers and contributes to
avoid failed revocation checks with the certification authorities
who need more time to propagate new certificates like

38
being valid for their OCSP responders. Over time, try to extend
this period of "warming" lasts 1 to 3 months. Likewise, do not wait until
that your certificates are about to expire to replace them. By leaving
several additional months, this would also help people whose
clocks are incorrect

5.2.5 Use of certificate signature algorithms

solid
The security of the certificate depends on the strength of the private key used to sign it.
the certificate and the strength of the hash function used in the signature.
Until recently, most certificates relied on the function of ha-
change SHA1, which is now considered insecure. Therefore,
we are in the process of switching to SHA256.
Starting in January 2016, you should not be able to obtain a certificate ...
cat SHA1 from a public certification authority. The SHA1 certificates
existing ones will continue to operate (with warnings in some na-
navigators), but only until the end of 2016.

5.3 Configuration
With the correct configuration of the TLS protocol on a server, you ensure
that your identification information is properly presented to visitors
of the site, that only secure cryptographic primitives are used
and that all known weaknesses are mitigated.

5.3.1 Use of complete certificate chains

In most deployments, a single server certificate is insufficient.
to build a chain, two or more certificates are required.
complete confidence. A common configuration problem occurs during the
deployment of a server with a valid certificate, but without all the certificates
necessary intermediaries. To avoid this situation, simply use all
the certificates provided to you by your certificate authority. A certi-
An invalid certificate renders the entire certificate chain of a server invalid and leads to
browser warnings. In practice, this problem is sometimes difficult
ficile à diagnostiquer car certains navigateurs peuvant reconstruire des chaînes
incomplete and some cannot. All browsers tend to
cache and reuse intermediate certificates.

5.3.2 Use of secure protocols

There are five protocols in the SSL/TLS family: SSL v2, SSL v3, TLS
v1.0, TLS v1.1 et TLS v1.2 :

39
 SSL v2 is not secure and should not be used. This version of
the protocol is so serious that it can be used to attack keys
RSA and sites with the same name even if they are on different servers
entirely different (the DROWN attack).
— SSL v3 is not very secure when used with HTTP (the POODLE attack
DLE) and low when used with other protocols. It is also
Element obsolete and should not be used.
TLS v1.0 is also an inherited protocol that should not be used
read, but it is still necessary in practice. Its major weakness
(BEAST) has been mitigated in modern browsers, but others
problems persist.
TLS v1.1 and v1.2 are both without known security issues, but
only TLS v1.2 provides modern cryptographic algorithms.
TLS v1.2 should be your main protocol as it is the only version
who offers modern authenticated encryption (also called AEAD). If
you do not support TLS v1.2 today, you have a lack of
security. In order to take care of the old clients, you will need to
not to support TLS v1.0 and TLS v1.1 for now. However-
However, you should remove TLS v1.0 in the near future. For example,
the PCI DSS standard will require all sites that accept payments by
credit card to eliminate support for TLS v1.0 by June 2018.
Work is currently underway to design TLS v1.3, the aim of which is
to eliminate all obsolete and insecure features and to provide
improvements that will secure our communication during the
following decades.

5.3.3 Use of secure encryption suites

To communicate securely, you first need to verify that you
communicate directly with the desired party (and not through an intermediary)
a person who listens) and exchanges data securely. In SSL/TLS
The encryption suites define how secure communication is established.
takes place. They are composed of different building blocks with the idea of s-
cure the diversity. If one of the building blocks proves to be weak or unstable,
you should be able to move on to another. You should mainly count
on AEAD schemes that provide authentication and key exchange
strong, persistent confidentiality and encryption of at least 128 bits.
Certain weaker suites can still be supported, provided
that they are only negotiated with older clients who do not take on
charge nothing better. There are several obsolete cryptographic primitives
which must be avoided:
Anonymous Diffie-Hellman (ADH) are suites that do not provide
an authentication.
NULL cipher suites that provide no encryption.
Export encryption sets are not secure when they
are negotiated in a connection between two entities, but they can

40
 also be used against a server that prefers stronger suites
(the FREAK attack)
The sequences with low numbers (typically 40 and 56 bits) use
an encryption that can easily be broken.
RC4 is not secure.
3DES is slow and weak.
Use the following list configuration, designed for RSA and ECDSA keys,
as a starting point:
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
Attention: We recommend that you first test your configuration.
TLS in a staging environment, transfer the changes into
the production environment only when you are certain that everything
works as expected. Please note that the above is a list
generic and that not all systems (especially the older ones) are not
compatible with all these suites. That is why it is important to test
First. The above configuration uses standard TLS suite names.
Some platforms use non-standard names, please refer to the
documentation of your platform for more details. For example, the names
the following suites would be used with OpenSSL:
ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-ECDSA-AES128-SHA
ECDHE-ECDSA-AES256-SHA
ECDHE-ECDSA-AES128-SHA256
ECDHE-ECDSA-AES256-SHA384
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-RSA-AES256-GCM-SHA384

41
 ECDHE-RSA-AES128-SHA
ECDHE-RSA-AES256-SHA
ECDHE-RSA-AES128-SHA256
ECDHE-RSA-AES256-SHA384
DHE-RSA-AES128-GCM-SHA256
DHE-RSA-AES256-GCM-SHA384
DHE-RSA-AES128-SHA
DHE-RSA-AES256-SHA
DHE-RSA-AES128-SHA256
DHE-RSA-AES256-SHA256

5.3.4 Selection of the best encryption suites

In the SSL v3 protocol versions and later, clients
present a list of supported cipher suites and the servers choose
a sequence of the list to use for the connection. Not all servers are
unable to do this correctly, however, some will choose the
first suite covered in the client's suite list. The servers that
selecting the best available encryption suite is essential for
obtain the best security.

5.3.5 Persistent Confidentiality

Persistent confidentiality (sometimes also called persistent confidentiality
perfect) is a protocol function that allows for secure conversations
which do not depend on the server's private key. With encryption suites
who do not provide persistent confidentiality, someone who can recover
Compromising the private key of a server can decrypt all encrypted conversations.
previously recorded. You must support and prefer ECDHE suites
in order to allow persistent confidentiality with web browsers
last. To support a wider range of clients, you should also
use DHE sequences alternately after ECDHE. Avoid key exchange
RSA unless absolutely necessary. Our default configuration pro-
The one posed in subsection 5.3.3 contains only sequences that provide a
persistent confidentiality.

5.3.6 Use of strong key exchange

For key exchange, public sites can generally choose between
the Diffie-Hellman key exchange (DHE) and its variant ECDHE. There are other
key exchange algorithms, but they are generally unstable in one way or
from another. RSA key exchange is still very popular, but it does not provide
but persistent confidentiality. In 2015, a group of researchers published
new attacks against DHE; Their work is known as the attack
of [Link] researchers discovered that low DHE key exchanges
resistance (for example, 768 bits) can easily be broken and that some

42
1024-bit DHE groups known can be broken by state agencies.
To be sure, if you deploy DHE, configure it with at least 2048 bits of
security. Some older clients (for example, Java 6) may not
support this level of strength. For performance reasons, most of
servers prefer ECDHE, which is both stronger and faster. The secp256r1
(also called P-256) is a good choice in this case.

5.3.7 Mitigation of known issues

There have been numerous attacks against SSL and TLS in recent years,
but they generally should not concern you if you have
up-to-date software while following the advice of this chapter. However, nothing is
perfectly secure, that's why it's good to keep an eye on what
happens safely. Quickly apply vendor patches if and
when they are available, otherwise rely on workarounds
to mitigate risks.

5.4 Performance
Safety is our main goal in this chapter, but we must
also pay attention to performance
A secure service that does not meet performance criteria will be without
no doubt abandoned. With a correct configuration, TLS can be quite
fast. With modern protocols, for example HTTP/2, it could even
to be faster than clear communication.

5.4.1 Avoiding too much security

The establishment of a cryptographic handshake, used to ...
Secure connections are an operation for which the cost is high.
influenced by the size of the private key. Using a key that is too short
is somewhat insecure, but using a key that is too long will lead to very
high and slow operation. For most websites, use keys
RSA greater than 2048 bits and ECDSA greater than 256 bits, it's a gas-
CPU power theft can harm the user experience. From
even, there are few advantages to increasing the strength of ephemeral key exchange.
mothers beyond 2048 bits for DHE and 256 bits for ECDHE. There is none
obvious advantage of using encryption stronger than 128 bits.

5.4.2 Resumption of user session

The resumption of the session is a performance optimization technique.
which allows saving the results of costly cryptographic operations
and reuse them for a certain time. A mechanism for recovering its-
Invalid or non-functional submission can introduce a performance penalty.
significant.

43
5.4.3 Use of WAN Optimization and HTTP/2
These days, TLS overheads do not come from crypto operations.
graphics starved by the CPU, but due to network latency. the establishment
of a TLS connection, which can only start after the establishment is completed
TCP liaison requires a new exchange of packets and will be more costly if
you are far from the server. The best way to minimize latency is to avoid
to create new connections, that is to say to maintain existing connections
open for a long time (keep-alives). Other techniques that provide
Good results include support for modern protocols such as HTTP/2
and the use of WAN optimization (generally via distribution networks
distribution of content.

5.4.4 Public content cache

When communicating with SSL/TLS, browsers can assume
that all traffic is sensitive. They generally use memory to hide
some resources, but once you close the browser, all the content
may be lost. To achieve improved performance and allow
long-term caching of certain resources, mark the resources
public (for example, images) as public.

5.4.5 Use of OCSP aggregation

The OCSP agglomeration is an extension of the OCSP protocol that issues
revocation information within the framework of the TLS handshake, directly from
the server. As a result, the client does not need to contact the servers
OCSP for out-of-band validation and the total TLS connection time is
considerably reduced. The OCSP agglomeration is an optimization technique.
tion importante, mais vous devez savoir que tous les serveurs web ne fournissent
no solid OCSP aggregation implementations. Associated with an authority
of certification that has a slow or unreliable OCSP responder, these web servers
can create performance issues. For better results, if-
analyze the failure conditions to see if they could have an impact on
your availability.

5.4.6 Use of Fast Cryptographic Primitives

In addition to providing better security, our configuration on the suite
recommended encryption also offers the best performance. In
as much as possible, use CPUs that support AES
led by the material. After that, if you really want another advantage of
performance (probably not necessary for most sites), consider
to use ECDSA keys.

44
5.5 HTTP protocol and the security of applications
tions
The HTTP protocol and the surrounding platform for content delivery
web applications continued to evolve rapidly after the birth of SSL. To
as a result of this evolution, the platform now contains features
teas that can be used to defeat encryption. In this section, we
we will present these features, as well as how to use them safely
security.

5.5.1 Encryption of everything

The fact that encryption is optional is probably one of the issues.
of security. We see the following problems:
No TLS on sites that need it.
The sites that have TLS but do not implement it.
- Sites that mix TLS and non-TLS content, sometimes even in the
same page.
Sites with programming errors that undergo TLS.
Although many of these issues can be mitigated if you know exactly
What you do, the only reliable way to protect the com-
Communication on the website is to enforce encryption without exception.

5.5.2 Elimination of mixed content

Mixed content pages are those that are transmitted via TLS, but
include resources (for example, JavaScript files, images,
CSS files) that are not transmitted via TLS. These pages are not se-
careful. An active attacker of a man in the middle (MITM: Man In The
Middle) can detach from a single unprotected JavaScript resource, by
example and divert the entire user session. Even if you follow the advice
from the previous section and encrypt your entire website, you still risk
réccupérer certaines ressources non cryptées depuis des sites web tiers.

5.5.3 Third-party Trust

Websites often use third-party services activated via JavaS code
script downloaded from another server. A good example of such a service
is Google Analytics, which is used on large parts of the web. Such a
the inclusion of third-party code creates an implicit trust connection that gives eff
effectively give the other party full control over your website. The third party can
not to be malicious, but the major providers of these services are increasingly
Moreover, they are considered as targets. The reasoning is simple: if a large
the supplier is compromised, the attacker automatically accesses all sites
which depend on the service. If you follow the advice in section 5.5.2, at least

45
your third-party links will be encrypted and thus protected against MITM attacks. This-
however, you should go further: learn about the services you use and
remove them, replace them with safer solutions or accept the risk of
their use. A new technology called sub-resource integrity (SRI):
Subresource integrity could be used to reduce potential exposure.
via third-party resources.

5.5.4 Cookie Security

To be properly secured, a website requires TLS, but also all
these cookies are explicitly marked as secure when they are created.
The lack of cookie security allows an active MITM attacker to cause
want information with smart tips, even on 100% sites
Hashes. For better results, consider adding integrity validation
cryptographic or even encryption to your cookies.

5.5.5 Secure HTTP Compression

The CRIME attack 2012 showed that TLS compression cannot be
implemented securely. The only solution was to completely disable
the TLS compression. The following year, two other variants of attack have
TIME and BREACH tracking focused on secrets in HTTP response bodies
compressed using HTTP compression. Unlike compression
TLS, HTTP compression is a necessity and cannot be disabled.
Thus, to solve these attacks, modifications to the application code
must be carried out.
The TIME and BREACH attacks are not easy to carry out, but if any-
that one is sufficiently motivated to use them, the impact is approximately
equivalent to a successful cross-site request forgery (CSRF) attack.

5.5.6 Deployment of HTTP Strict Transport Security

HTTP Strict Transport Security (HSTS) is a security mechanism for TLS.
It was designed to ensure that safety remains intact even in the case of the
configuration problems and implementation errors. To enable the protection
HSTS, you add a new response header to your websites. Then,
the browsers that support HSTS (all modern browsers)
at that moment) apply it. The goal of HSTS is simple: after activation,
it does not allow any unsecured communication with the website using it. It
achieve this goal by automatically converting all links into text
clear secured. In addition, it also disables certificate warnings.
Clicking (certificate warnings are an indicator of a MITM attack
active). Studies have shown that most users click on these
warnings, it is therefore in your best interest to never allow them. The addition
Support for HSTS is the most significant improvement possible for the se-
TLS security of your websites. New sites should always be designed

46
with HSTS in mind and the old sites converted to support them as much as
possible and as soon as possible. For better security, consider using the
HSTS preload, which integrates your HSTS configuration into browsers
modern, which makes the first connection to your site secure.
The following configuration example enables HSTS on the primary hostname.
pal and all its subdomains for a period of one year, while allowing
also the preload:
Strict-Transport-Security: max-age=31536000; includeSubDomains; pre-
load

5.5.7 Deployment of the Content Security Policy

The Content Security Policy (CSP) is a
security mechanism that websites can use to restrict the function-
browser operation. Even if originally designed to handle Cross-Site
Scripting (XSS), CSP is constantly evolving and supports functionalities
teas that are useful for improving TLS security. In particular, it can be
used to restrict mixed content when it comes to third-party websites, for
which HSTS does not help them. To deploy CSP to prevent the content
mixed thirds, use the following configuration:
Content-Security-Policy: default-src https: 'unsafe-inline' 'unsafe-eval';
connect-src https : wss :
Note: This is not the best way to deploy CSP. In order to provide
an example that does not stop anything except the mixed content, we had to disable certain ones
default security features. Over time, as you ...
To learn more about CSP, you should modify your policy to bring them back.

5.5.8 Caching of sensitive content

All sensitive content must be communicated only to the concerned parties.
born and treated accordingly by all devices. Although the proxies do not
do not see the encrypted traffic and are unable to share the content between the
users, the use of application distribution platforms based on
the cloud is increasing, which is why we need to be very careful when
you specify what is public and what is not.

5.5.9 Consideration of other threats

TLS is designed to address a single aspect of confidentiality in security.
and the integrity of communication between you and your users, but there is
the many other threats you have to face. In most
In some cases, this means that your website has no other weaknesses.

47
5.6 Validation
With many configuration parameters available for adjustments
It is difficult to know in advance what impact certain changes
will have. Furthermore, changes are sometimes made accidentally.
Software updates can introduce silent changes.
For this reason, we advise you to first use an evaluation tool.
Complete SSL / TLS evaluation to verify your configuration to ensure
that you start safely, then periodically to ensure that
stay safe. For public websites, we recommend testing the
free SSL Labs server.

5.7 Conclusion
The recommendations and best practices section is offered to auditors in order to
to help them for a better SSL/TLS configuration of a server.

48
Conclusion and Perspectives

This internship was an opportunity to focus on the field of security.

computer audit. Our mission aimed to create an audit tool.
on the SSL/TLS configuration of a server in order to allow for detailing the
supported protocols and cipher suites. After a thorough study that
deals with the different open-source solutions available on the client side and server side
server, we managed to choose the open source project sslyze for its speed
in the server part and the sslhaf project thanks to its accuracy in the part
client
Following this experience and in response to its challenges, we will soon want to
improve this solution by adding new features such as:
User account management.
The use of the nmap tool that provides the level of security
of a sequence of encryption.
The addition of vulnerability tests for the most recent attacks.
The adaptation of our tool to the TLS 1.3 protocol.

49
Bibliography

[1][Link] (15Avril 2017)

[2] [Link]
default methods used(24 Février 2017)
[3][Link] (3 Mars 2017)
[4] [Link] (10 Mars 2017)
[5][Link] (28Avril 2017)
[6] [Link] (6 March 2017)
[7] [Link] May 20
2017)
[8] T. Dierks; E. Rescorla (August 2008). "The Transport Layer Security (TLS)
Protocol, Version 1.2
[9]A. Freier; P. Karlton; P. Kocher (August 2011). "The Secure Sockets Layer
(SSL) Protocol Version 3.0

50