PREVIOUSLY ON PART I: we have spoken about the reasons for securing our communications, the problems and the attacks to an encrypted communication, the strength of an encrypted communication and the different steps to open a connection, how we generate keys, the different types of certificate and some related concept like which crypto algorithm should be used, which lifetime a key should have, problems like outdated OCSP responders, client clock skew and what is a chain of trust. Finally we created a self signed certificate.
Monday afternoon, after lunch, we started speaking about the TLS configuration. The handshake (2-way) includes Authentication AND Key Exchange. Each server keeps a list of capabilities that, for each request, is checked against the capabilities of the client in order to adopt the best solution for the choice of all the protocols/algorithms. The entries in this list can be split in 3 not bounded parts: the authentication part, the cipher part and the integrity part. One example may be TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 where TLS_ECDHE_RSA is the authentication part, AES_128_GCM is the is the cipher one, and SHA256 is the integrity (MAC). The bigger the MAC length, the stronger the integrity check. GCM is the mode of the AES, not exactly sure what it is, but for AES, GCM is the safest value.There are other cipher algorithms, like RC4, but you must be sure that they are safe (RC4 is broken). AES is so widely used that lot of machines has an hardware acceleration for computing AES. Anyway not all of them, for example mobile devices, for this reason servers may want to list in their capabilities also the Chacha algorithm, that is faster.
When configuring a server for using crypto, please ensure that your entries in the list of capabilities is used as a priority list (so that YOU decide which algorithms to use first)
ECDHE and DHE are protocols for key exchange. KEY EXCHANGE is a big problem for setting up the security. Let’s think about the overhead: in the 2-way handshake you have the setup of a communication starting with 2 round trip from client to server and return. Network latency has to be counted 4 times, then. There are 2 techniques to improve that: Session ID, exactly as a Session ID for a web server, the client records the id and the server stores all the info for resuming the communication if the client contact the server again later.
To avoid storing data on the server, Session Tickets can be used. Basically, instead of storing the key on the server, the server sends an encrypted ticket to the client with all the information about the connection. When the client reconnect to the server, it sends the ticket: the server can verify the authenticity of the ticket using its own keys, and it cas resume the communication with the data stored into the ticket.
We then made an example of RSA key exchange: the client sends the hello client message (with capabilities). The server sends its certificate with the public key and signature in the hello server message. At this point the client encrypts half of the key with the pub key of the server and sends it to the server that decrypts it, the server add half of the key and do the same. At the end both have the full key.
Then we did an example of DHE exchange: we chose 2 numbers as private key. For the server was A=27 and for the client was B=16. The server and the client decide a modulo, P=103, and they take one primitive root, like G=5. The server computes S=(G^A)%P and send it to the client (5^27%103 is 94) and the same does the client with B (S=G^B%P=5^16%103=32) and send it to the server. Now they can both find the symmetric key by computing the power of the other side number to their inner number modulo P (for the server S=32^27%103=23). Both of them will have the same result: 23. This is the symmetric key. For better understanding it, look at wikipedia page. The E of DHE means Ephemeral cause every time new keys are generated and they cannot be compromised.
Other concept to be known in this field are: Server Name Indication (SNI) is an extension to TLS that allows the client to declare which domain wants to connect to during the first phase of the handshake (the hello client). This solves the problem of virtual hosts for which several domains are served by the same server (that then he would not be able to know which certificate to send back). Of course it is an information the client should be able to provide (meaning that the browser should be aware of this extension).
SSL Stripping is related to the default protocol used by browsers. Indeed if you type an url in your browser without specifying the protocol, every browser defaults to HTTP. If a server wants you to transmit over a secure connection, it can reply with a 301 status redirecting to its url with https. Fine, but vulnerable. Indeed the first attempt is in clear mode, and it is possible to have a MITM attack. There are other techniques to stripe https connection over http and attack with a MITM, but I leave better explanations to more specific posts.
Mixed Content refers to the bad behaviour of mixing https (crypted) content with http one in web pages. Mixed content can be active (like javascript scripts that can actively change the behaviour of your machine) or passive (like an image)
The previous two problems (SSL Stripping and Mixed Content) can be solved with HSTS, an header that a web server can add to the first response to a client (the one over http when the client requests for the very first time the page) to inform the browser that every time the browser wants that page, it has to trust only secure connections. From that moment till the expiration of the header the browser won’t consider any content coming from an insecure source. The very first connection remains vulnerable, but then the http header expiration can be update in any following requests. To remove the weakness of the very first connection that enables the HSTS, any domain can request to be added into a PRELOAD List, a list of website that want to be accessed only in a secure connection. The PRELOAD List is plugged into the source code of the browsers, so you don’t need any insecure connections to download and use it.
Last concept of this post (and we are still on the first day of training) is the CSP (Content Security Policy), it instruct the browser about location or type of content allowed to be loaded. It was first created for fighting the cross site scripting. Directives are like “block-all-mixed-content” or “upgrade insecure requests“, the last one used for telling to the browser that all the content that it should load over http has to be loaded over https (useful for old webpages that have links for http material). CSP comes with a report mode that tells to the browser to send a report of its actions to an API as json instead of blocking the behaviours related to its directives.
Stay tuned for the next wonderful post on this topic!!!
Leave a Reply