45
Cryptography is something fundamental in web, because it provides us with privacy and security. It’s even possible that this is standard at HTTP 2.
My question is: How does encryption via HTTP work? I believe that there is a key that is unique for each connection between server and client, otherwise (if the key was always the same) someone could intercept the connection easily. I’ve heard of "certificates" necessary for the thing to work, but I don’t know how it works.
29
The protocol is considerably robust, but can greatly burden communication between client and server.
The list of 'steps' ( and its code in a SSL Packet) for the establishment of an SSL connection is as follows:
0x00 Hello Request
A connection is established by the client to the server.
0x01 Client Hello
The client identifies itself (in our case, the browser) and informs its characteristics (accepted SSL versions, which protocols and ciphers are supported, the session ID the client would like to use.)
0x02 Server Hello0x0B Certificate (when present)0x0C Server Key Exchange0x0D Certificate Request0x0E Server Hello Done0x0F Certificate Verify0x10 Client Key Exchange0x14 FinishedFinished marks the moment when data can be encrypted and bidirectionally sent.These steps can be viewed in the following way (graphic in English):
As of this moment, all data traffic is encrypted using the keys negotiated between the two parties.
Sources:
Description of the Secure Sockets Layer (SSL) Handshake
SSL Introduction with Sample Transaction and Packet Exchange - Cisco
29
Edgar Muniz Berlinck already gave an overview, and the response of Onosendai describes the protocol very well, but I would like to complement it with the motivation behind the protocol (and make some minor corrections).
When a client (say, Alice) connects to a server (Bob) over the Internet, this connection is indirect - Alice sends the message to Charlie, who sends it to Dave, who sends it to Mallory who sends it to Bob. Bob responds to Mallory, who passes it on to Dave, who sends it to Charlie who sends it to Alice. It is not always known which exact path the packages will take, nor can it be guaranteed with certainty that all nodes are honest. How to ensure that the communication between Alice and Bob is confidential (no one in the middle sees her), righteous (no one in the middle changes it) and authentic (at the other end of the communication there has to be Bob, not someone posing as Bob)?
Cryptography - originated centuries ago in the military, and only popularized in the civil environment after the emergence of the Internet - seeks to solve this problem: sending secure messages through an insecure communication channel. There are two types of encryption: symmetric (the two pairs share a secret) and asymmetric (one of them has a secret that the other does not have). SSL/TLS uses both: asymmetrical to ensure authenticity, and symmetrical to confidentiality and integrity.
Then answering your first question: there is a different key to each connection - the symmetrical one, which is the result of the "handshake protocol" (Handshake) as described by Onosendai. However, the pair(s) of asymmetric keys(s) (the server’s public and private key, and optionally also the client’s) do not change frequently. But that’s no problem, because the private is never revealed, and the public - as its name says - does not need to be kept secret...
(Updating: after a rereading of the Handshake, I realize that there is a public/private pair that is generated at each connection and used to transmit the asymmetric key. A "key cipher key" - Key Encryption Key or KEK. However, the pair whose public key is contained in the certificate, this yes does not change frequently: its typical validity is two years, and it is only used to sign, never to encrypt.)
And how is this key pair (public, private) used to guarantee authenticity? First, the server sends the client its public key. Eventually, he sign something with its private key - proving to the client that he really is the "owner" of the public key. So far so good, but how can Alice be sure that the key she received saying came from Bob really came from Bob? Here comes a case of the egg and the chicken:
Se Alice you already know Bob’s public key (i.e. has saved Bob’s key associated with his computer identity - for example, the domain that belongs to Bob), so it’s quiet. Otherwise, she needs someone she trusts to step in (how to check Bob’s signature if Alice has nothing to compare it to? ). This is done through a certified. A certificate is:
There’s more than one way to do this - Certification Authorities (CA), Trust Networks (Web of Trust), Notaries, etc. I can’t tell you what the SSL/TLS protocol supports, but the most common is the use of Certification Authorities. They are, roughly, a set of companies whose public key already comes inlaid in the software you use. If you are using Firefox, for example, you can check who they are by Ferramentas -> Opções -> Avançado -> Certificados -> Certificados (de novo) -> Autoridades.
(Note that the ICP-Brasil is not on that list... already noticed that whenever you try to enter a secure Government website the browser gives an invalid certificate alert?)
If you have for example a website, and you want it to be available safely to the general public, there’s not much to do but pay for one of these companies to verify your identity and sign your certificate (creating the certificate is the least one can do). Taking into account that not every OS or browser recognizes all CA. But if all you want is to distribute an application to a restricted audience (say, something that will only be accessible to your company’s employees) you can also create a Root Certificate - used to sign other certificates - and install it manually in the users' browser. Thus avoiding having to pay for this service.
(Always remembering that the means to distribute this root certificate has to be safe. Egg and chicken, remember? You could take it by hand, on a flash drive for example, but to distribute via internet you would need again help from someone you already trust...)
Closing then, after the delivery and verification of the certificate (which is a relatively slow process, as pointed out by Onosendai, but only the first time, when the certificate is not in the cache), it is necessary to ensure the authenticity of Alice. This can be done also via certificates, but the most common is to omit this step (later, the use of a simple username and password tells the site who the user is - without being part of the SSL/TLS protocol). After both are authenticated, symmetric encryption is used - this is very fast - for normal communication.
P.S. I didn’t want to put as part of the answer, because it’s more of a Rant that an objective and neutral opinion, but I suggest reading of that article by Bruce Schneier (in English) to know better "the hidden side" behind the Cas. This scheme in my opinion is a zone, just a CA have its root certificate compromised for all sites in the world to be vulnerable... I hope that this will improve a little in the future, with the evolution of the HTTP and SSL/TLS protocols.
+1 - Excellent description of implications and dependencies.
CA is nothing more than a "notary" certification that you purchase from it is nothing more than a virtual "stamp" on its website that it is who it says it is. Obviously you don’t need to stamp an internal memo from your company. But a sales site needs to be officially identified, just as tax bills need an official stamp/stamp. Without Cas, e-commerce would be very vulnerable to malicious sites. Additionally, CA has an expiration date, usually one year.
If a CA root certificate is compromised it simply disqualifies it (and needs to send new Cas to all of its customers)
@jean when she finds out that it has been compromised, right? Until then, anyone who has a copy of it can sign arbitrary certificates. My problem is not with the Trusted third parties - I agree with you that your presence makes our life much easier (web of trust is an interesting concept, but difficult to implement at scale). The problem is that whichever CA can issue certificates to whichever site - even those who already have a certificate in a different CA. An interesting alternative would be, for example, the Convergence
17
I develop apps for Facebook and all these should be run by HTTPS. For this I need to install a certificate on my server (Jboss in this case, since I use java).
Well, when people access my application my Jboss identifies that it is an access by HTTPS and presents the certificate to the browser, confirming that the url actually accessed is the url that should be accessed (There was no attack of any kind and such a thing as to compromise your connection and redirect you to another place).
As for encryption, my server has two keys: a key public and a private. On a first access will be installed in your browser a public key of my server, which will be used (during the Handshake) to encrypt the information sent by you to my server - then establishing a shared key (symmetrical).
My server can use this key to decrypt the content sent by you and your browser can also use it to decrypt information sent by my server.
So I guarantee that what I get was sent by you and what you receive was sent by me.
I hope I’ve helped.
Edit
Just add that for web applications the certificate is considered valid if it is issued by a valid certification organization and you have to pay for this certificate, which has an expiration period. You can develop/test with a certificate issued by yourself but will not serve the production environment.
In practice the browser will give some feedback to the user on the validity of the certificate how to ask if he wants to (risk to) continue or change the color of the address bar.
You can go to the websites of these certification organizations to get an idea of how it works (and how much it costs) they usually have a FAQ and provide support, including on how to use the certificates.
Great question and a good answer. I only add that for web applications the certificate is considered valid if it is issued by a valid certification organization (and you have to pay for this certificate). You can develop/test with a certificate issued by yourself (but it will not suit the production environment). The practical difference is that the browser will give you some feedback on the validity of the certificate how to ask if you want to continue or change the address bar color
Well remembered @jean! You can edit the answer if you want.
Currently there are some companies that provide free and valid certificates, which are accepted by most modern browsers. Just a search (good) on the web. But beware, not always the "famous" Cas or that "most know" are the best in this regard.
@The change in the color of the address bar denotes a higher level of care when verifying the identity of the site (so it is more expensive, intended for larger companies, and only applicable if your company already has X years of operation). And it’s good to mention that there are cases where a certificate issued by yourself is good enough, see my answer for more details. But I agree that - on a site aimed at the general public - the recognition by a Certification Authority that major Oses and browsers trust is even inevitable (but you don’t always have to pay for the certificates themselves).
Now that I read better: "...will be installed in your browser a public key from my server, which will be used to encrypt the information sent by you to my server" It’s not quite like this: if the key is public, anyone can encrypt with it! And what the server encrypts with the private key, anyone can read. The permanent public/private pair is not used for encryption, only for digital signature. A second pair is used for encryption, and this generated dynamically, so I understood the "Client Key Exchange" in the Onosendai response.
@mgibsonbr Maybe I didn’t use the correct terminology because I’m not an expert in information security. Feel free to edit my answer to make her richer.
@Edgarmunizberlinck Done! I don’t like to be pedantic, but when it comes to a security issue it’s important that the information is accurate. :)
Obs: A bar address green are for (business), and is only applied when you have an SSL certificate with extended validation installed on your server. The simplest certificates (For people) is just one padlock green.
Browser other questions tagged http cryptography ssl
You are not signed in. Login or sign up in order to post.
+1 per describing Handshake
– jean