13/11/2014. Pa rt 2 S S L i m p a c t a n d o p t i m i s a t i o n. Pa rt 1 A b o u t S S L C e r t f i c a t e s. W h a t i s S S L / T L S

Transcription

1 13/11/2014 SSL/TLS: IMPACT AND SOLUTIONS With I ntroduction W h a t i s S S L / T L S Pa rt 1 A b o u t S S L C e r t f i c a t e s Pa rt 2 S S L i m p a c t a n d o p t i m i s a t i o n

2 INTRODUCTION What is SSL / TLS? Baptiste Assmann HAProxy What is SSL? The purpose of SSL History of SSL / TLS Overview of a TLS connection Glossary Timeframe

3 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 SSL when speaking about TLS Stands at the layer 5 of the OSI model 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 It s the s in HTTPs, IMAPs, POPs, etc

4 Purposes of the protocol 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 TLS connection peer2

5 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

6 Overview of a TLS connection Glossary 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)

7 Overview of a TLS connection TLS connection timeframe Client (3) Verify server certificate (5) Generate session key (1) Client Hello Supported cipher suites (2) Server Hello Cipher Suite, Server certificate, public key, Server Random (4) Client Key Exchange Client Random, pre-master secret (encrypted with server s public key) (6) First message Server (5) Generate session key, session ID Step 1: Step 2: Step 3: Step 4: Step 5: Step 6: client hello: clients opens a TCP connection and send the following information: supported ciphers suite. 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. client verifies server s certificate (self signed, expired, etc ) client uses the server s public key to encrypt its random and pre-master secret. both the client and the server generate the session key using client random, server random and premaster secret. a first message is then exchange over the ciphered connection

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

9 PART 1 A bout SSL Certificates 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

10 What is the role of an SSL certificate? SSL: Secure Socket Layer Replaced in 1999 by TLS: Transport Layer Security 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. 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 )

11 3 possible levels of validation DV (Domain Validation) 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) 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 EV (Extended Validation) 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

12 2 options / add-ons Secures an unlimited number of subdomains. We often refer to a Wildcard certificate by using a «*» (star). Example :*.ssl247.co.uk can secure blog.ssl247.co.uk, mail.ssl247.co.uk, server.ssl247.co.uk + Easier to manage; Cheaper than buying for each single sudomain; Very flexible a certificate - If the SSL certificate is compromised, then all the servers using the Wildcard certificate are compromised; Not compatible with all mobile device operating systems; Not compatible with Extended Validation 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 + Usually cheaper to buy SANs rather than several certificates; If your websites are hosted on a single server, a SAN won t require different IP addresses for each domain name - The CA will still operate a vetting process for each SAN; Requires good management if you have several SANs; More expensive than a normal or Wildcard certificate

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

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

15 2 types of encryption in SSL SSL algorithms: encryption 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) a) Assymetric encryption > 3 main key exchange algorithms RSA Authored by Ron Rivest, Adi Shamir and Leonard Adleman DSA Digital Signature Algorithm ECC Elliptic Curve Cryptography NEW! b) Symmetric encryption > 1 main standard: AES (Advanced Encryption standard) Cipher suite = combination of authentication / key exchange / encryption algorithms

16 SSL algorithms: authentication 1 main algorithm : SHA (Secure Hash Algorithm) Used in secured connections to prove the integrity and authenticity of a message to the receiver. Standard hash algorithm in SSL certificates. SHA-1 phasing out, moving to SHA-2 SHA-1 = 160-bit fingerprint 2fd4e1c67a2d28fced849ee1bb76e7391b93eb12 Vs. SHA-2 = 256-bit fingerprint e3b0c44298fc1c149afbf4c8996fb92427ae4 1e4649b934ca495991b7852b855 Google is accelerating the deprecation The next 3 releases of Chrome will progressively display warning icons on websites secured with SHA-1 certificates SHA-1 Certificates concerned by Google s action: Expiring between 01/06/2016 and 31/12/2016 Expiring from 01/01/2017

17 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 OV certificate with SAN I have a Lync project with 2 servers : Edge + Proxy sip.contoso.com meet.contoso.com lyncdiscover.contoso.com lyncweb.contoso.com dialin.contoso.com OV certificate with Wildcard+SAN I have an e-commerce website shop.contoso.com Single domain EV certificate Symantec

18 PART 2 SSL impact a nd optimisation 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

19 Deployment modes 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.. SSL pass through or forward SSL offloading client SSL HAProxy Encrypted data SSL server client SSL HAProxy Clear data clear server SSL cut through or bridging client SSL HAProxy Clear data SSL server

20 Deployment modes HAProxy and SSL pass through or SSL forward client SSL HAProxy Encrypted data SSL server frontend ft_www mode tcp bind :443 default_backend bk_www backend bk_www mode tcp server s :443

21 HAProxy and SSL offloading Deployment modes client SSL HAProxy Clear data clear server frontend ft_www mode http bind :443 ssl crt mycrt.pem default_backend bk_www backend bk_www mode http server s :80

22 Deployment modes HAProxy and SSL cut through or bridging client SSL HAProxy Clear data SSL server frontend ft_www mode http bind :443 ssl crt mycrt.pem default_backend bk_www backend bk_www mode http server s :443 ssl

23 TLS extension: SNI TLS and IPv4 exhaustion 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.

24 TLS extension: SNI TLS and IPv4 exhaustion 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 (3) Verify server certificate (1) Client Hello Supported cipher suites, Server Name Indication (2) Server Hello Cipher Suite, Server certificate, public key, Server Random Server chooses the certificate based on SNI sent by the client

25 HAProxy and SNI Working as a TLS endpoint TLS and IPv4 exhaustion Tell HAProxy to load all the certificates available in a directory: (validated at certificates in production) frontend ft_www bind :443 ssl crt /etc/haproxy/certs/ Path to a default certificate, used when clients don t send SNI: frontend ft_www bind :443 ssl crt /etc/haproxy/certs/default.pem crt /etc/haproxy/certs/ To Log SNI information, use the ssl_fc_sni sample fetch in a log-format directive: log-format...%[ssl_fc_sni]... Working in TLS passthrough mode Route TLS connections to different server farms frontend ft_ssl bind :443 tcp-request inspect-delay 5s tcp-request content accept if { req_ssl_hello_type 1 } use_backend bk_webmail if { req.ssl_sni i owa.domain.com mail.domain.com } use_backend bk_sharepoint if { req.ssl_sni i sharepoint.domain.com }

26 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/OpenSSL performance on a single core of a i7 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 suite is very important!!! Read:

27 TLS impact on performance CPU Use HAProxy s global section to manage SSL parameters (HAProxy and above) global ssl-default-bind-ciphers <copy paste the intermediary SSL cipher suite> tune.ssl.default-dh-param 2048 ssl-default-bind-options no-sslv3 Log client User-Agent and negotiated cipher suite capture request header User-Agent len 128 log-format...{sslv/sslc}... Example of log output:...{tlsv1/ecdhe-rsa-aes128-sha}... Adapt your cipher suite to your client pattern and not to make SSLlabs happy!!! In case of trouble, HAProxy will log TLS handshake error, without any other information. This part is handled by OpenSSL library Tune HAProxy SSL session key cache: global tune.ssl.cachesize # default to tune.ssl.lifetime 600 # default to 300 seconds

28 TLS impact on performance 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: Deployment mode Computation Total memory required TLS pass through 1000 * 50K 50 MBytes TLS offloading 1000 * (50K + 64K) 114 MBytes TLS cut through 1000 * (50K + 64K + 64K) 178 MBytes

29 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: 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!!!

30 Disabling TLSv1.0 or not??? TLS impact on clients Compatibility matrix errors without TLSv1.0: (non exhaustive list)

31 Disabling TLSv1.0 or not??? TLS impact on clients Compatibility matrix with TLSv1.0: (non exhaustive list)

32 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

33 TLS impact on Web applications Protect application cookie HAProxy can enforce the Secure flag on application cookies: Backend myapp acl https ssl_fc acl secured_cookie res.hdr(set-cookie),lower -m sub secure rspirep ^(set-cookie:.*) \1;\ Secure if https!secured_cookie 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: acl https ssl_fc acl app_cookie req.cook(jsessionid) -m found acl path_logout path i /logout.jsp http-request redirect /logout.jsp if!https app_cookie!path_logout

34 Impact of SSL offloading The main difficulty of SSL offloading is that clients browse over HTTPs and application server is reached over HTTP: client SSL HAProxy Clear data clear server 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

35 Impact of SSL offloading tell HAProxy to log some useful information: capture response header Location len 32 capture response header Set-Cookie len 32 Tell the application server which protocol was used on the client side: http-request set-header X-Forwarded-Proto https if { ssl_fc } http-request set-header X-Forwarded-Proto http if!{ ssl_fc } Application server should adapt content based on this header Track errors and adapt server s responses to client side connection type: rspirep ^Location:\ Location:\ if { ssl_fc } rspirep ^Location:\ Location:\ if { ssl_fc } Don t forget the Secure flag (see a few slide above)

36 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!!!

37 SSL / TLS weaknesses Security of the SSL protocol 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 ) SSL protocol: Beast attack: use an up to date SSL librairy SSLv3 Poodle: disable SSLv3: global ssl-default-bind-options no-sslv3 Downgrade attack prevention (TLS_FALLBACK_SCSV) TLS compression

38 Moving to SSL Conclusion 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 s flexibility, 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

39 USEFUL LINKS - > decode an SSL certificate - > test your SSL server - > info about moving to TLS - > choose the right certificate - > use a 30-day free SSL certificate to run tests on your servers info@ssl247.co.uk +44 (0) contact@haproxy.com