Webinar SSL English

SSL/TLS: IMPACT AND SOLUTIONS FOR YOUR WEB APPLICATIONS
Introduction
What is
SSL / TLS
Part 1
About SSL Certficates
Part 2
SSL impact and
optimisation
With
13/11/2014

SSL / TLS: IMPACT AND SOLUTIONS FOR YOUR WEB APPLICATIONS
Baptiste Assmann–HAProxy
•What is SSL?
•The purpose of SSL
•History of SSL / TLS
•Overview of a TLS connection
•Glossary
•Timeframe
INTRODUCTION
What is SSL / TLS ?

What is SSL?
•SSL(Secured Socket Layers) first released in 1994
•IETF standardized SSL protocol into TLS(Transport Layer Security) in 1999
•People carry on using SSLwhen speaking about TLS
•Stands at the layer 5 of the OSI model
It’s the ‘s’ in HTTPs, IMAPs, POPs, etc…
OSI model
Layer 7 –application
HTTP, POP, IMAP
Layer 6 –presentation
Layer 5 –session
SSL/ TLS
Layer 4 –transport
TCP
Layer3 –network
IP
Layer2 –link
Layer1 -physical

Confidentiality: nobody between the peers of a TLS connection can understand the content
Integrity: no data are altered when transmitted over a TLS connection
Authentication: each peer of a TLS connection can check the other one is the one he says to be
(In these slides, we’ll focus only on the server side)
peer1
peer2
TLS connection
Purposes of the protocol

History of SSL / TLS
•SSL(Secured Socket Layers)
•First version: Netscape in 1994
•SSL 2.0: 1995
•SSL 3.0: 1996
•IETF standardization: TLS(Transport Layer Security)
•TLS 1.0: 1999 (based on SSL 3.0)
•TLS 1.1: 2006
•TLS 1.2: 2008
•TLS 1.3: 2015

Overview of a TLS connection
Before starting, we need to clarify a few definitions:
•Client hello: client side TLS connection initialization
•Server hello: server side TLS connection initialization response
•TLS handshake: phase where the client and the server negotiate the way the connection is established
•Client random: client side random string unique for each TLS session
•Server random: server side random string unique for each TLS session
•Pre-master secret: binary data provided by client and used to generate the session key
•Cipher suite: unique identifier of algorithms describing a TLS connection
•Session key: key for symmetric ciphering, result of the TLS handshake
•Session ID: TLS session ID associated to the Session Key and which can be used later by both the client and the server (resume)
Glossary

Overview of a TLS connection
TLS connection timeframe
•Step 1:
client hello: clients opens a TCP connection and send the following information: supported ciphers suite.
•Step 2:
server hello: server selects a cipher suite from the client list. The response also contains the server random
the server sends its certificate and public key to the client.
•Step 3:
client verifies server’s certificate (self signed, expired, etc…)
•Step 4:
client uses the server’s public key to encrypt its random andpre-master secret.
•Step 5:
both the client and the server generate the session keyusingclient random, server randomandpre- master secret.
•Step 6:
afirst message is then exchange over the ciphered connection
Client
Server
(1) Client Hello
Supportedciphersuites
(2) Server Hello
CipherSuite, Server certificate, public key, Server Random
(3)
Verifyserver certificate
(4) Client Key Exchange
Client Random, pre-master secret (encryptedwithserver’spublic key)
(5)
Generatesession key
(5)
Generatesession key, session ID
(6) First message

Resuming a TLS connection
TLS connection timeframe
•Step 1:
client hello: clients opens a TCP connection and send the following information: supported ciphers suite and a SSL session ID to resume.
•Step 2:
server hello: server selects a cipher suite from the client list.
the server sends its certificate and public key to the client.
•Step 3:
client verifies server’s certificate (self signed, expired, etc…)
•Step 4:
a first message is then exchange over the ciphered connection
No session keys to compute.
Client
Server
(1) Client Hello
Supportedciphersuites, session key ID
(2) Server Hello
CipherSuite, Server certificate, public key
(3)
(4) First message

François Marien –SSL247®
•What is the role of an SSL certificate?
•Levels of validation
•Options for certificates: SAN and Wildcard
•The certificate ordering process
•Certificate chain
•SSL algorithms: encryption & authentication
•Examples
PART 1
About SSL Certificates

What is the role of an SSL certificate?
SSL:
Secure Socket Layer
An SSL certificate is a data file which binds a public cryptographic key to a domain name. When installed on a server, it activates the SSL/TLS protocol.
TLS:
Transport Layer Security
Replaced in 1999 by
3 main roles
Encrypting data during online transactions
> Can anyone read the data I am exchanging?
Authenticating the server
> Am I talking to the server it claims to be?
Proving the integrity of a content
> Can anyone tamper with the data exchanged?
Proving the identity of the organisation controlling the domain!
(depending on the validation level…)

3 possible levels of validation
•Data encryption
•Validation of the domain name + organisation authentication
•Padlock + https appearing in the browser
•Details about the organisation are displayed in the certificate information
•Issued within 1-2 days
Vetting = longer issuance time
•Data encryption
•Strict authentication, respects industrial norms
•Green bar + padlock + https appearing in browsers
•Details about the organisation are displayed in the certificate information
•Issued within 5-6 days
Long and strict vetting = maximum confidence from visitors
•Data encryption
•Validation of the domain name
•Padlock + https appearing in the browser
•Certificate issued within less than 10 minutes
No vetting = fast issuance time
OV (Organisation Validation)
EV (Extended Validation)
DV (Domain Validation)

2options / add-ons
Secures an unlimited number of subdomains.
We often refer to a Wildcard certificate by using a «*» (star). Example:*.ssl247.co.ukcan secure blog.ssl247.co.uk, mail.ssl247.co.uk, server.ssl247.co.uk…
+
Easiertomanage;Cheaperthanbuyingacertificateforeachsinglesudomain;Veryflexible
-
IftheSSLcertificateiscompromised,thenalltheserversusingtheWildcardcertificatearecompromised;Notcompatiblewithallmobiledeviceoperatingsystems;NotcompatiblewithExtendedValidation
Often used for Unified Communications (UC) to secure Microsoft apps or Mobile Device Managers.
Example: ssl247.com, exchange.ssl247.com, ssl247.net,
new-ssl247.net
-
TheCAwillstilloperateavettingprocessforeachSAN; RequiresgoodmanagementifyouhaveseveralSANs; MoreexpensivethananormalorWildcardcertificate
+
UsuallycheapertobuySANsratherthanseveralcertificates;Ifyourwebsitesarehostedonasingleserver,aSANwon’trequiredifferentIPaddressesforeachdomainname

The ordering process
The request
The vetting & issuance
The installation
1
2
3
CSR = CertifiateSigning Request
Applicant’s
information
Private key
Public key
When the CA issues your SSL certificate , they officially guarantee that the public key which was contained in your CSR belongs to www.yourdomain.com , and they also guarantee that www.yourdomain.com is controlled by your organisation(except for DV: no vetting).

Certificate chain / certification path
Root certificate = the CA’s own certificate!
A root can become linked to an intermediate by “signing” (authenticating) it.
Trust
infrastructure
Intermediate CA = the root’s delegate.
The intermediate is in charge of “signing” (authenticating) SSL certificates.
SSL certificate.
The SSL certificate is issued by the CA, then signed by an intermediate,
which is signed by a root certificate.

SSL algorithms: encryption
RSA –Authored by Ron Rivest, AdiShamir and Leonard Adleman
DSA –DigitalSignatureAlgorithm
ECC –EllipticCurveCryptography –NEW!
a) Assymetricencryption > 3 main “key exchange algorithms”
2 types of encryption in SSL
a) Assymetric encryption: used at the beginning of an encrypted session , during the «key exchange»
(needs 2 keys, a public and a private)
b) Symmetric encryption: used when the session key has been exchanged
(needs one temporary, session key)
b) Symmetric encryption > 1 main standard: AES (Advanced Encryption standard)
Cipher suite = combination of authentication / key exchange / encryption algorithms

SSL algorithms: authentication
1mainalgorithm:SHA(SecureHashAlgorithm)
Usedinsecuredconnectionstoprovetheintegrityandauthenticityofamessagetothereceiver.
StandardhashalgorithminSSLcertificates.
SHA-1 Certificates concerned by Google’s action:
•Expiring between 01/06/2016 and 31/12/2016
•Expiring from 01/01/2017
SHA-1phasingout,movingtoSHA-2
SHA-2 = 256-bit fingerprint
Vs.
2fd4e1c67a2d28fced849ee1bb76e7391b93eb12
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
Google is accelerating the deprecation
SHA-1 = 160-bit fingerprint
The next 3 releases of Chrome will progressively display warning icons on websites secured with SHA-1 certificates

Case Studies: typical requests
“ I need to secure my Microsoft Exchange server”
•mail.contoso.com
•mail.contoso-local.com
•autodiscover.contoso.com
•autodiscover.contoso-local.com
•legacy.contoso.com
•sip.contoso.com
•meet.contoso.com
•lyncdiscover.contoso.com
•lyncweb.contoso.com
•dialin.contoso.com
OV certificatewithSAN
OV certificatewithWildcard+SAN
•shop.contoso.com
“ I have a Lync project with 2 servers : Edge + Proxy”
Single domainEV certificate
Symantec
“ I have an e-commerce website”

Baptiste Assmann–HAProxy
•TLS and IPV4 exhaustion
•HAProxy and SNI
•TLS impacts:
•on performance
•on clients
•on Web applications
•SSL offloading
•SEO
•Security of the SSL protocol
PART 2
SSL impact and optimisation

Deployment modes
HAProxy
server
•SSL pass through or forward
•SSL offloading
•SSL cut through or bridging
client
SSL
SSL
HAProxy
server
client
SSL
clear
HAProxy
server
client
SSL
SSL
Encrypteddata
Cleardata
Cleardata
•HAProxy can be used in 3 different modes in front of services requiring SSL
There is no ‘good’ neither ‘bad’ way. There is a mode which meet your requirements.
•Requirements are dictated by the application, the servers, the hardware capacity, etc..

server
client
SSL
SSL
HAProxy
Encrypteddata
HAProxy and SSL pass through or SSL forward
frontend ft_www
mode tcp
bind 10.0.0.1:443
default_backendbk_www
backend bk_www
mode tcp
server s1 10.0.0.11:443
Deployment modes

HAProxy
server
client
SSL
clear
Cleardata
HAProxy and SSL offloading
frontend ft_www
mode http
bind 10.0.0.1:443 sslcrtmycrt.pem
backend bk_www
mode http
server s1 10.0.0.11:80
Deployment modes

HAProxy
server
client
SSL
SSL
Cleardata
HAProxy and SSL cut through or bridging
frontend ft_www
mode http
bind 10.0.0.1:443 sslcrtmycrt.pem
backend bk_www
mode http
server s1 10.0.0.11:443 ssl
Deployment modes

TLS and IPv4 exhaustion
TLS extension: SNI
•The certificate presented by the server must match the hostname, otherwise the client sends a warning
•Lessons learned until now:
•When the server has to send the certificate, it doesn’t know which service the client is trying to browse
•The service host name is an HTTP information, not available at TLS layer
Since it is impossible for the server to create a relation between one of its certificates and the service reached by the client, a best practice was to affect one IP address per certificate.
Wildcard certificates, SAN, multi domain helps, but this is not scalable.

TLS extension: SNI
•In April 2006, the RFC 4366 is published and introduces TLS Extensions.
•One of this extension is named Server Name Indication, shortened as SNI.
•Basically, during the client hello, the client sends a string containing the name of the service the above layer (IE HTTP) is trying to reach.
•Based on this string, the server can now select the appropriate certificate
•Both client and server must support SNI
Client
Server
(1) Client Hello
Supportedciphersuites,
Server Name Indication
(2) Server Hello
CipherSuite, Server certificate, public key, Server Random
(3)
Server chooses the certificate based on SNI sent by the client

HAProxy and SNI
Working as a TLS endpoint
•Tell HAProxy to load all the certificates available in a directory: (validated at 50000 certificates in production)
•Path to a default certificate, used when clients don’t send SNI:
•To Log SNI information, use the ssl_fc_snisample fetch in a log-formatdirective:
Working in TLS passthroughmode
•Route TLS connections to different server farms
frontend ft_www
bind 10.0.0.1:443 sslcrt/etc/haproxy/certs/
frontend ft_www
bind 10.0.0.1:443 sslcrt/etc/haproxy/certs/default.pemcrt/etc/haproxy/certs/
log-format ...%[ssl_fc_sni]...
frontend ft_ssl
bind 10.0.0.1:443
tcp-request inspect-delay 5s
tcp-request content accept if { req_ssl_hello_type1 }
use_backendbk_webmailif { req.ssl_sni–iowa.domain.com mail.domain.com }
use_backendbk_sharepointif { req.ssl_sni–isharepoint.domain.com }

TLS impact on performance
CPU
•CPU usage:
•Key computation is very expensive, furthermore with 2048 RSA keys. Scales very well with number of processes
•TLS resume is cheaper. Scales well up to 3 processes
•Ciphering a request on an established connection is cheap with modern CPU and AES- NI instruction
•HAProxy/OpenSSLperformance on a single core of a i7 CPU @3.4GHz:
•key computation: around 600/s (2048 bits)
•TLS resume per second (TLS 1.2): around 12000/s
•TLS bandwidth: 4.3Gb/s
•Now, you know why it is important to be able to resume a TLS connection!!!! (x20 gain of performance!)
The choice of the cipher suiteis very important!!!
Read: https://wiki.mozilla.org/Security/Server_Side_TLS

CPU
•Use HAProxy’sglobal section to manage SSL parameters (HAProxy 1.5.8 and above)
•Log client User-Agent and negotiated cipher suite
•Example of log output: ...{TLSv1/ECDHE-RSA-AES128-SHA}...
•Adapt your cipher suite to your client pattern and not to make SSLlabshappy!!!
•In case of trouble, HAProxy will log TLS handshake error, without any other information. This part is handled by OpenSSL library
•Tune HAProxySSL session key cache:
global
ssl-default-bind-ciphers <copy paste the intermediary SSL cipher suite>
tune.ssl.default-dh-param2048
ssl-default-bind-options no-sslv3
capture request header User-Agent len128
log-format ...{sslv/sslc}...
global
tune.ssl.cachesize50000 # default to 20000
tune.ssl.lifetime600 # default to 300 seconds

Memory
•Memory usage (no tuning, system and HAProxy defaults):
•Raw TCP connection passing through HAProxy requires 50K of memory
•With OpenSSL, add 64K of memory per TLS connection.
•Memory requirements for a peak of 1000 TLS connections:
Deploymentmode
Computation
Total memory required
TLS pass through
1000 * 50K
50 MBytes
TLS offloading
1000 * (50K + 64K)
114 MBytes
TLS cutthrough
1000 * (50K + 64K + 64K)
178 MBytes

TLS impact on clients
Forward proxies
•Some companies may forbid HTTPs on their forward proxies
•Web sites should be available over both HTTP and HTTPs (public data only)
•Web applications should be available over HTTPs only
•Some forward proxies does SSL inspection, making SSL useless:
https://www.google.fr/search?&q=SSL+inspection+appliance
Low capacity devices
•Low CPU resource means huge impact on performance
•Battery consumption increased
•Add latency and delay printing
•Usually, they support only outdated SSL protocols and can’t be updated
•The choice of the cipher suite is very important!!!

Disabling TLSv1.0 or not ???
•Compatibility matrix errors without TLSv1.0: (non exhaustive list)

Disabling TLSv1.0 or not ???
•Compatibility matrix with TLSv1.0: (non exhaustive list)

TLS impact on Web applications
•In order to support the switch to TLS, a web application must be “agile”.
•Links must be adapted to scheme (http or https). Prefer using relative links.
•HTTP responses should match the right scheme (http or https) and port (80 or 443)
Sometimes we must switch to SSL bridging mode
•What should be ciphered:
•Pages with sensitive / personal information
•All content of a page must be ciphered
•Application cookies should never be sent over a plain connection
•Mixing 2 host headers on a single page to download static content and over HTTP and dynamic content over HTTPs may lead to warnings in the browser

TLS impact on Web applications
•HAProxy can enforce the Secure flag on application cookies:
The ‘Secure’ flag tells the browser to never send this cookie over a clear connection
•Force a logout if the cookie has been sent over a clear connection:
Protect application cookie
Backendmyapp
aclhttpsssl_fc
aclsecured_cookieres.hdr(Set-Cookie),lower-m subsecure
rspirep^(set-cookie:.*) 1;Secure if https !secured_cookie
aclhttpsssl_fc
aclapp_cookiereq.cook(JSESSIONID) -m found
aclpath_logoutpath–i /logout.jsp
http-requestredirect/logout.jspif !https app_cookie!path_logout

Impact of SSL offloading
•The main difficulty of SSL offloading is that clients browse over HTTPs and application server is reached over HTTP:
•Check list:
•HAProxy must inform the server which protocol is being used by the client
•Server must adapt responses (Location, Set-Cookie, etc…)
•Links from the body of the page must be adapted too
HAProxy
server
client
SSL
clear
Cleardata

Impact of SSL offloading
•tell HAProxy to log some useful information:
•Tell the application server which protocol was used on the client side:
Application server should adapt content based on this header
•Track errors and adapt server’s responses to client side connection type:
•Don’t forget the Secure flag (see a few slide above)
capture responseheader Locationlen32
capture responseheader Set-Cookie len32
http-requestset-header X-Forwarded-Proto https if{ ssl_fc}
http-requestset-header X-Forwarded-Proto httpif !{ ssl_fc}
rspirep^Location:http://(.*):80(.*) Location:https://1:4432 if { ssl_fc}
rspirep^Location:http://(.*) Location:https://1 if { ssl_fc}

Search Engine Optimisation
•Lately, Google has announced that protocol scheme (HTTP / HTTPs) from web sites will be used in their ranking algorithm: HTTPs will get more points
Important to move to SSL if your business relies on google ranking
•If your business doesn’t rely on google ranking, then no worries!!!

Security of the SSL protocol
SSL / TLS weaknesses
•Lately, some vulnerabilities on SSL has been reported
•OpenSSL Library: ensure you’re running the latest OpenSSL library available for your operating system
•Heartblead
•CCS (CVE 2014-0224)
•SSL protocol:
•Beast attack: use an up to date SSL librairy
•SSLv3 Poodle: disable SSLv3:
•Downgrade attack prevention (TLS_FALLBACK_SCSV)
•TLS compression
global
ssl-default-bind-options no-sslv3

Conclusion
Moving to SSL
•Moving to SSL is not straight forward:
•if the application is SSL-ready, then no problem
•If the application is not SSL-ready, then it may work (worst case, use SSL bridging mode)
•In rare cases, an update of the application may be needed
•Don’t forget to run an audit before
•Bear in mind that the type of client can also have an impact on your SSL stack (backward compatibility, limited features and ciphers, etc..)
•HAProxy’sflexibility, reporting and performance is your best friend during this move!
Choosing the right SSL certificate
•An SSL certificate provides more than encryption
•You need to find the right balance between the levels of validation, the levels of encryption and the add-ons (Wildcard / SAN) you need
•SSL247®can help you choose the right certificate(s) for all your needs

info@SSL247.co.uk
+44(0)207 060 3775
www.SSL247.co.uk
contact@haproxy.com
+1-857-366-5050 www.haproxy.com
USEFUL LINKS
-https://www.ssl247.com/ssl-tools/certificate-decoder> decode anSSL certificate
-https://www.ssllabs.com/ssltest/> test your SSL server
-https://istlsfastyet.com/> info about moving to TLS
-https://www.ssl247.com/?wizard#> choose the right certificate
-https://www.ssl247.com/ssl-certificates/brands/GeoTrust/geotrust-trial> use a 30-day free SSL certificate to run tests on your servers

Webinar SSL English

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Webinar SSL English

Similar a Webinar SSL English (20)

Más de SSL247®

Más de SSL247® (10)

Último

Último (20)

Webinar SSL English