Sunday, January 12, 2014
Labels:
HTTPS
,
SSL
The events of 2013 have raised awareness about the capability to eavesdrop on Internet conversations many thought were protected from eavesdropping. There are many articles about HTTPS, SSL, and [Perfect] Forward Secrecy, but I've found that none really reference the information in a visual way. Since we're all primarily visual creatures, I think it would be helpful to some to post a more visual-oriented reference to this discussion.
The Basics
First, a review of the OSI model. This model sets out a visual representation of what happens when information is transmitted from one system to another, such as when your home computer, laptop, or tablet loads a web page. Think of the OSI model as an information workflow process that systems use to either receive data or send it out. The model is organized into 7 layers, depicted here:
The mechanisms of HTTPS, SSL, and Perfect Forward Secrecy take place at the top three layers: Application, Presentation, and Session. More specifically, and for the sake of simplification, we'll say they happen at the Application and Session layers.
When you sit down at your machine and are ready to perform some online banking or shopping, this is what typically happens. You type in your bank's website, and your machine sends an HTTP request to the banking or ecommerce site.
It's at this stage where the bank or ecommerce site will send a redirect message to your browser (Internet Explorer, Chrome, Firefox, etc) providing instructions to contact the server back using an HTTPS request. Let's narrow our scope down on that part of the conversation:
When communicating sensitive information such as banking (account numbers) or ecommerce (credit card numbers), we don't want that data to be passed "in the clear" because someone could easily see what we're typing. Banks and retail stores don't want to be held accountable for letting someone steal your data, so they attempt to secure the communication when you access the portal. That's why in the graphic above, when you send a "clear text" request, the organization's server will typically send your browser an instruction to send a new request in a secure way. The browser knows where that new location is via the location response header.
Now our browser will begin secure communication negotiation with the banking or ecommerce server. Before the browser sends the request for the web page again, it establishes an agreed-upon secure communication method with the server.
Notice how in the graphic above I only focus on the SSL part of the conversation? It's important to note that SSL is independent of the HTTP application protocol. You can send other types of traffic over SSL such as File Transfer Protocol, Internet Content Adaptation Protocol, and Simple Mail Transfer Protocol. When we think of our banking and ecommerce sites, we always see the https, which is HTTP over SSL. Below is an illustration, using the same example above:
The Details
Now on to [Perfect] Forward Secrecy. What exactly does it mean, and why do I bracket out the "Perfect"? Perfect Forward Secrecy (PFS) is a level up from Forward Secrecy (FS), and both are improved where no implementation at all is used.
How do they protect the encrypted traffic? Using the Diffie-Hellman exchange, they ensure that the keys exchanged between "Home PCs" and servers are done so in a secure manner. It's a psuedo-randomization of the session key so that the asymmetric keys can be exchanged.
To clarify, in the picture above where we see the SSL session established, without using PFS or FS the server would not randomize the keys, using the same keys in conversations with however many "Home PCs" wanted to communicate.
The danger of handling encryption/decryption of SSL messages this way is that if the private key is compromised in anyway, all traffic collected using this keyring could then be decrypted.
Using Forward Secrecy, each conversation with each different "Home PC" would use the Diffie Hellman algorithm set to generate random session keys to determine the secure key exhange of the RSA keyring. Because the key exchange mechanism is different per "Home PC", gaining access to the private RSA key would have to be run through the Diffie-Hellman algorithm to find the key exchange used for each session.
Now, running the recovered (hacked?) private key along with the Diffie-Hellman algorithm would only reveal communication between that one "Home PC" the key was cracked for and the server.
And lastly, Perfect Forward Secrecy uses different session keys within the same conversation with each "Home PC" so that multiple keys are used per conversation:
So, what does this mean in terms of security?
We eliminate the capability of someone without key-breaking tools to eavesdrop when we switch from HTTP to HTTPS. SSL without PFS or FS means that if someone is able to crack the key used, then they have access to all conversations between that server and all systems with which it communicates. SSL with Forward Secrecy operations prevent all conversations from being monitored by the cracking of one key, but if someone does crack that key, then they would get access to all conversations between that server and one endpoint. Finally, SSL with Perfect Forward Secrecy ratchets up the difficulty even more, because now an eavesdropper must crack multiple keys within a single conversation.
The focus here is the number of keys involved, and increasing the number of keys increases the time it takes to break those keys.
Self Assessment
So, how can you test if a website uses forward secrecy or perfect forward secrecy? Check out Qualys' SSL Labs. When you run a report on a domain, there's a check to see if it supports Forward Secrecy. Since there was a recent article about Yahoo enabling HTTPS by default for its mail service, let's run a report:
Looks like Yahoo isn't there yet. How about GMail?
What's the main hesitation and why wasn't it already implemented? Performance. By increasing the number of keys, we're adding more overhead to the server. In spite of that, I think we can safely predict that this is a feature that will be gaining steam in 2014.
Reference:
http://news.netcraft.com/archives/2013/06/25/ssl-intercepted-today-decrypted-tomorrow.html
HTTPS, SSL, and [Perfect] Forward Secrecy
The Basics
First, a review of the OSI model. This model sets out a visual representation of what happens when information is transmitted from one system to another, such as when your home computer, laptop, or tablet loads a web page. Think of the OSI model as an information workflow process that systems use to either receive data or send it out. The model is organized into 7 layers, depicted here:
The mechanisms of HTTPS, SSL, and Perfect Forward Secrecy take place at the top three layers: Application, Presentation, and Session. More specifically, and for the sake of simplification, we'll say they happen at the Application and Session layers.
When you sit down at your machine and are ready to perform some online banking or shopping, this is what typically happens. You type in your bank's website, and your machine sends an HTTP request to the banking or ecommerce site.
It's at this stage where the bank or ecommerce site will send a redirect message to your browser (Internet Explorer, Chrome, Firefox, etc) providing instructions to contact the server back using an HTTPS request. Let's narrow our scope down on that part of the conversation:
When communicating sensitive information such as banking (account numbers) or ecommerce (credit card numbers), we don't want that data to be passed "in the clear" because someone could easily see what we're typing. Banks and retail stores don't want to be held accountable for letting someone steal your data, so they attempt to secure the communication when you access the portal. That's why in the graphic above, when you send a "clear text" request, the organization's server will typically send your browser an instruction to send a new request in a secure way. The browser knows where that new location is via the location response header.
Now our browser will begin secure communication negotiation with the banking or ecommerce server. Before the browser sends the request for the web page again, it establishes an agreed-upon secure communication method with the server.
Notice how in the graphic above I only focus on the SSL part of the conversation? It's important to note that SSL is independent of the HTTP application protocol. You can send other types of traffic over SSL such as File Transfer Protocol, Internet Content Adaptation Protocol, and Simple Mail Transfer Protocol. When we think of our banking and ecommerce sites, we always see the https, which is HTTP over SSL. Below is an illustration, using the same example above:
The Details
Now on to [Perfect] Forward Secrecy. What exactly does it mean, and why do I bracket out the "Perfect"? Perfect Forward Secrecy (PFS) is a level up from Forward Secrecy (FS), and both are improved where no implementation at all is used.
How do they protect the encrypted traffic? Using the Diffie-Hellman exchange, they ensure that the keys exchanged between "Home PCs" and servers are done so in a secure manner. It's a psuedo-randomization of the session key so that the asymmetric keys can be exchanged.
To clarify, in the picture above where we see the SSL session established, without using PFS or FS the server would not randomize the keys, using the same keys in conversations with however many "Home PCs" wanted to communicate.
 |
| NOTE: The "same" key is depicted above via the color purple |
The danger of handling encryption/decryption of SSL messages this way is that if the private key is compromised in anyway, all traffic collected using this keyring could then be decrypted.
Using Forward Secrecy, each conversation with each different "Home PC" would use the Diffie Hellman algorithm set to generate random session keys to determine the secure key exhange of the RSA keyring. Because the key exchange mechanism is different per "Home PC", gaining access to the private RSA key would have to be run through the Diffie-Hellman algorithm to find the key exchange used for each session.
Now, running the recovered (hacked?) private key along with the Diffie-Hellman algorithm would only reveal communication between that one "Home PC" the key was cracked for and the server.
And lastly, Perfect Forward Secrecy uses different session keys within the same conversation with each "Home PC" so that multiple keys are used per conversation:
So, what does this mean in terms of security?
We eliminate the capability of someone without key-breaking tools to eavesdrop when we switch from HTTP to HTTPS. SSL without PFS or FS means that if someone is able to crack the key used, then they have access to all conversations between that server and all systems with which it communicates. SSL with Forward Secrecy operations prevent all conversations from being monitored by the cracking of one key, but if someone does crack that key, then they would get access to all conversations between that server and one endpoint. Finally, SSL with Perfect Forward Secrecy ratchets up the difficulty even more, because now an eavesdropper must crack multiple keys within a single conversation.
The focus here is the number of keys involved, and increasing the number of keys increases the time it takes to break those keys.
Self Assessment
So, how can you test if a website uses forward secrecy or perfect forward secrecy? Check out Qualys' SSL Labs. When you run a report on a domain, there's a check to see if it supports Forward Secrecy. Since there was a recent article about Yahoo enabling HTTPS by default for its mail service, let's run a report:
Looks like Yahoo isn't there yet. How about GMail?
What's the main hesitation and why wasn't it already implemented? Performance. By increasing the number of keys, we're adding more overhead to the server. In spite of that, I think we can safely predict that this is a feature that will be gaining steam in 2014.
Reference:
http://news.netcraft.com/archives/2013/06/25/ssl-intercepted-today-decrypted-tomorrow.html
Subscribe to:
Post Comments
(
Atom
)
No comments :
Post a Comment