Google Chrome 3.x opens the “how-not-to” way, but Firefox 3.5.x likes to “show off” with some “technical details”. IE8 also wants to “play”.
It can get slightly amusing sometimes. :)
Note that we won’t mention ECC bellow(Elliptic Curve Cryptography) to keep this blog entry from becoming too long, as ECC is not very used as currently writing. Also we won’t mention DSS certificates also, as they are rarely used today.
Google Chrome 3.x
Either is RC4 128 bit:
Or AES 128 bit:
Makes no difference to Google Chrome 3.x.
Longer the better, 3DES “silently tops” AES 128-bit:
It does not seem to go into the details of such a connection, or I did not find from where to display this info.
Note that depending on which Windows OS Chrome 3.x is installed, you may be able to use Chrome 3.x with a weak symmetric encryption algorithm like DES, apparently without receiving any warnings. For example Chrome 3.x on Windows XP SP3 supports TLS_RSA_WITH_DES_CBC_SHA.
I did not notice a warning or any visual effects about that on the browser window, but if we look(you look, don’t you ;) ) at the Security Information we are notified about the weak encryption:
It does not warn/notify about short server RSA keys though, like 512 bits RSA keys(RSA DHE-based cipher suites are not supported by the Windows Crypto API). Just says the connection is encrypted with x bits if the server uses a certificate containing such a RSA key.
Also Chrome 3.x recognizes an Extended Validation certificate and the user can notice the green text when such a certificate is used.
Extended Validation certificate:
“Normal” certificate:
Firefox 3.5.x
The “good part” of Firefox 3.5.x compared with Google Chrome 3.x is that it actually displays the symmetric encryption algorithm used:
Firefox 3.5.x recognizes an Extended Validation certificate and the user can notice the green bar when such a certificate is used.
Extended Validation certificate:
“Normal” certificate:
Now the technical details I’ve mentioned before.
First, I wasn’t aware that RC4 128-bit is still a “High-grade encryption” algorithm:
And it continues with a “technical explanation”, rest assured: “It is therefore very unlikely that anyone read this page as it traveled across the network” because “Encryption makes it very difficult for unauthorized people to view information traveling between computers”.
Dear Firefox, the fact that the connection is encrypted (say with AES-128 128 bits) is just an overall part of the SSL/TLS equation, for example, above the cipher suite was TLS_RSA_WITH_AES_128_CBC_SHA, which means that this suite used the RSA key exchange, and during that process the client encrypted “something” with the server’s public key and sent it to the server. If the server’s RSA public key was 512 bits long(which you do not check), I sincerely doubt that “It is therefore very unlikely that anyone read this page as it traveled across the network”. To make such a “particular assuring assumption” about the specific page I’m viewing you actually need to quantify many moving and static parts related with this specific connection.
Mozilla.org sports a “technical document” on its web site(there is no mention about Firefox on that page, can’t say it has anything to do with Firefox or not, but a simple user may ran into it searching with Google about Firefox and SSL/TLS connection details, like I did), which not only is outdated, but sounds like a nice introduction to a snake oil algorithm: “Connection Encrypted. In general, the strength of an encrypted connection depends on the length of the keys use for encryption, measured in bits. The longer the key, the stronger the encryption—that is, the harder it is to for an unauthorized person to unscramble the encrypted information.”
Regarding Firefox 3.5.x and the "Medium-grade encryption. Somewhat stronger than low-grade encryption, using 56- or 64-bit keys." from that page, in case you may wonder, Firefox 3.5.x does not have enabled by default any cipher suites that use such a weak symmetric encryption algorithm. Also such a symmetric encryption algorithm is rated as “Low-grade encryption”(if we enable one just for testing to see what happens), and the experience is visually different.
IE8
IE8 recognizes an Extended Validation certificate and the user can notice the green bar when such a certificate is used.
Extended Validation certificate:
“Normal” certificate:
Note that depending on which Windows OS IE8 is installed, you may be able to use with IE8 a weak symmetric encryption algorithm like DES without receiving any warnings. For example IE8 on Windows XP SP3 by default supports TLS_RSA_WITH_DES_CBC_SHA.
Also it does not warn about short server RSA keys, like 512 bits RSA keys(RSA DHE-based cipher suites are not supported by the Windows Crypto API).
IE8 offers some details about the SSL/TLS version used(TLS 1.0 bellow for carbonwind.net), the symmetric encryption algorithm(AES 128 bit bellow for carbonwind.net) and the key exchange(RSA key exchange bellow for carbonwind.net, the server has a 1024-bits RSA key), which is quite nice(to view all these expand the Page menu and then click Properties):
Until fun begins…
As with Firefox, I wasn’t aware that RC4 128-bit still offers “High encryption”:
Perhaps this relates to DES offering “medium encryption”, say what Microsoft ?:
As said, no warnings about short server RSA keys, like 512 bits RSA keys(kind of expected if we look at the DES example from above):
Safari 4.x on Windows
I’m not very familiar with Safari 4.x on Windows(I don’t have a Mac), but I haven't noticed from where we can display some info about the SSL/TLS connection(please comment if you know how to do that). So I will say that Safari 4.x does not seem to make any (ambiguous) comments regarding the cipher suite used and Safari 4.x on Windows appears to have chosen a quiet and discrete profile on this matter. We can see details about the server’s certificate when clicking the padlock.
Safari 4.x on Windows recognizes an Extended Validation certificate and the user can notice when such a certificate is used as some green text is shown, if I put the mouse on it becomes green.
Extended Validation certificate:
“Normal” certificate:
Note that depending on which Windows OS Safari 4.x is installed, you may be able to use it with a weak symmetric encryption algorithm like DES without receiving any warnings. For example Safari 4.x on Windows XP SP3 by default supports TLS_RSA_WITH_DES_CBC_SHA.
Also it does not warn about short server RSA keys, like 512 bits RSA keys(RSA DHE-based cipher suites are not supported by the Windows Crypto API).
Opera 10.10
I left it last because it appears to be the best at this chapter, being ahead of its competitors in this area.
Similar with IE8, but easier to visualize by clicking the padlock, offers more details about the cipher suite(symmetric encryption algorithm(RC4 128 bits bellow for cia.gov), key exchange(RSA key exchange bellow for cia.gov, the server has a 1024-bits RSA key) and MAC(HMAC with SHA-1 bellow for cia.gov, actually you can’t say it’s HMAC, I’ve said so because we use TLS 1.0, if it was SSL 3.0 it would have been MAC with SHA-1)) and the SSL/TLS protocol used(TLS 1.0 bellow for cia.gov, SSL 3.0 for www.example.net):
Opera 10.10 recognizes an Extended Validation certificate and the user can notice the green bar when such a certificate is used.
Extended Validation certificate:
“Normal” certificate:
If the secure web site uses an Extended Validation certificate, extra details are provided in respect with the server’s certificate, it’s nice that it does not say “it can be guaranteed that no one else has read this page”, rather it makes that comment about “it can be guaranteed” in respect with the server’s identity since the server is using an Extended Validation certificate:
As can be noted from bellow it presents details about the DHE key exchange(shows the length of the ephemeral Diffie-Hellman keys), if a DHE-based cipher suite was used. To be noted that bellow we use DHE key exchange with RSA signatures, both the DHE keys and server’s RSA key are 1024-bits long. Opera would show the weakest between them, for example if the server’s RSA key is 2048-bits long and the DHE keys are 1024-bits long, 1024 bit will be shown by Opera, and vice-versa, for example if the server’s RSA key is 1024-bits long and the DHE keys are 2048-bits long, 1024 bit will be shown by Opera:
Actually Opera checks and warns when “a site is using an outdated encryption method”(also you may like to read this), and this check does not mean(like Firefox 3.5.x or Chrome 3.x) only to see if a weak symmetric encryption algorithm was used(Opera 10.10 does not have enabled by default such a weak symmetric encryption algorithm), it also checks other parameters of the SSL/TLS connection, like the server’s RSA key length, if is too short(I think less than 900 bits) will warn:
As a visual effect, if we continue, note the question mark on which if we can click to get details, bellow I have a short RSA key(512 bits) on the server’s certificate:
Not only that Opera checks the public key from the server’s certificate, but if you use a DHE-based cipher suite, it also checks the length of the ephemeral Diffie-Hellman keys(bellow the RSA key from the server’s certificate is 1024-bits long, but the ephemeral Diffie-Hellman keys are only 512 bits long, as a result, as we already said, shows the minimum from the two and warns about the encryption level):
When I made the first tests with the test web site using weak DHE keys, I've done that connecting by IP address(at this point I took Wireshark traces and checked the key exchange messages length), and Opera did not issue any warnings about the DHE keys, just a name mismatch warning:
Then when I was connecting by name, I've made a mistake and used the incorrect DH params on the test server, and did not take any Wireshark captures. At this stage, I was expecting no checks for the DHE key length based on the first tests so I've paid attention only to the warnings(= silly me). Thus, for a while I was under the impression Opera does not check the DHE params, actually I’ve emailed to Yngve N. Pettersen from Opera about this, but later I’ve managed to figure it out where I was wrong.
This also happens in reverse, connect by name to the server using a certificate with a CN set to an IP address and weak DHE keys:
Actually when you have a name mismatch, you may not see any weak DHE keys related warnings:
But you will see weak server RSA keys related warnings when you have a name mismatch(either you connect by name or IP address):
Note that if you use on the cert as CN an IP address, and connect by IP address, Opera does warn you about short DHE keys if you use a DHE-based cipher suite(not sure why in case of the TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA cipher suite also logs a second warning about the key used for encryption while for TLS_DHE_RSA_WITH_AES_128_CBC_SHA or TLS_DHE_RSA_WITH_AES_256_CBC_SHA not):
An additional explanation for the checks and warnings we saw above:
http://www.ietf.org/mail-archive/web/tls/current/msg02120.html
While using a stronger symmetric encryption algorithm as a general rule does make you use a more “modern” TLS cipher suite, it does not always really offer you any assurance in terms of an extra real world security strength for your TLS connection, for example switching from AES 128-bit to AES 256-bit likely, these days(using TLS 1.0(and its MD5&SHA-1 based PRF), 1024/2048 bits RSA keys, 1024 bits DHE keys) does not really buy you any extra real word security for your TLS connection. Indeed we may apply that rule for switching from RC4 or 3DES to AES 128-bit, but this logic does not apply all the time.
Probably a question arises from the security details of the SSL/TLS connection: who really looks at these ?
And since people tend to ignore server certificates warnings, probably they will tend to do the same with outdated encryption warnings.
Nevertheless, it’s good to have such details/warnings for the people who pay attention to such details(I know I do, and occasionally I look at the security details of the SSL/TLS connection made to certain servers). And it’s only good if it’s done correctly, instead of naming RC4 128-bit as a high-encryption algorithm(note that RC4 128 bit used with SSL/TLS is still a strong encryption algorithm, but strong does not automatically mean High, in OpenSSL 1.0.0-beta4 RC4 128-bit based cipher suites are shown under MEDIUM) or DES a medium-encryption algorithm or something, otherwise(done incorrectly) perhaps is better to just forget about all these details.
Also probably Opera’s outdated encryption warnings will come quite handy when the switch from the 1024-bits RSA keys certificate will become more stringent(probably not many years from now). Actually you can set the Minimum Security Level from Opera’s Security Prefs, but to be honest I did not quite figure it out how this works(if I put if at ‘5’, and the server uses a 1024-bits RSA key I will get that encryption outdated warning, or if I put it to ‘4’ it will flag (most) connections as not being secure but not say why):
