It occurred to me more than once, that when I suggested that a URL should better be served in HTTPS, I have been replied that there was no need for that because that URL didn’t host any confidential data. The data is not confidential, OK, but still critical, as an alteration of the hosted data may result in serious damage in the consumer data security. And, precisely, TLS does not only grant confidentiality in the data transmission, but also authenticity and integrity. I may not expect you to do it, but if you really want, here is the RFC 5246. As you’ve guessed already, I won’t talk about confidentiality in this note.
Regarding integrity, it’s quite simple, there is a hash of the transmitted data, following an algorithm defined in the ciphersuite (the HMAC) and combined with a secret previously shared between the stakeholders during the TLS negotiation, at the beginning of the connection. For those who enjoyed reading the RFC 5246, this part is described here: RFC 2104.
This is for ensuring that what I get from the network is really what has been sent by my partner.
About authenticity, meaning the guarantee that the entity talking to me is really the one it pretends to be, it is based on Public Key Cryptography: my partner will provide his public key accompanied with a certificate, the well-known X.509 certificate.
But that’s not enough: as the certificate is presented by the server to anyone connecting to it, it would be easy to keep a copy of it and then impersonate its identity thanks to a DNS spoofing or a man-in-the-middle attack which are far from being impossible.
Thus, I have to prove that:
- I’m really the owner of the certificate
- A trusted third party has certified that I was allowed to disclose that certificate, that is, that I’m really the one whose name is indicated.
- The first point can be achieved with the private key. Of course it is not about showing the private key alongside the public key as my partner would just have to copy it on the fly. No, it is about answering a challenge. I won’t give a whole lecture about Public Key Cryptography, but in short the idea is that my partner will transmit a message ciphered with my public key and I will have to decode it with the private - secrete - key. In our case (meaning the verification of the public key that has been presented by the server) the message is the premaster secret that will later be used for ciphering the data or the dh parameters that will be used by the parties to agree upon a common secret, depending on the cipher suite.
- Regarding the second issue, my certificate has to be signed by the trusted third party, some entity that is known by my partner (or at least its user agent / browser) and who is considered as trustworthy. This is the certificate authority (CA).
This being said, do YOU personally know the certificate authorities that are trusted on your behalf by your browser? I won’t talk in this post of the trust we can grant (or not) to the CA, as this question is a topic in itself.