Interesting article from The Age about Melbourne’s Citylink (Transurban) falling foul of a Google Chrome error: There’s no space like Chrome
Leaving aside the introduction, with its very amusing description of Google Chrome OS as:
an internet-infused operating system for computers that takes on Microsoft’s MS-DOS
… it talks about the Google Chrome browser refusing to connect with the Citylink web site due to an SSL error.
I tried to connect (I have an account there) and sure enough got an error when trying to logon.
Here’s the detail from Google:
ERR_SSL_WEAK_SERVER_EPHEMERAL_DH_KEY
This error can occur when connecting to a secure (HTTPS) server. It means that the server is trying to setup a secure connection but, due to a disastrous misconfiguration, the connection wouldn’t be secure at all!In this case the server needs to be fixed. Chrome won’t use insecure connections in order to protect your privacy.
You may find that the site works in other browsers. This is because other browsers, unknowingly or intentionally, work around the broken servers. But this doesn’t change the fact that the servers have a glaring security hole and should be fixed.
Technical details
This error message is triggered if the SSL/TLS handshake attempts to use a public key, smaller than 512 bits, for ephemeral Diffie-Hellman key agreement.
For website administrators
If your website has this problem, either:
1. use a 1024-bit (or larger) Diffie-Hellman key for the DHE_RSA SSL cipher suites, or
2. disable all DHE SSL cipher suites.
The Age article seems to assume that Citylink must use a 1024 bit key… but then, if the writer thinks Google Chrome OS is trying to compete with MS-DOS, it’s clear he may not be the most IT-savvy person.
My reading of the error is that it’s a combination of the DHE keu agreement and the small key that is the problem. I’m not a net security expert, but that’s what point 2 appears to be saying.
It’s certainly not the case, as implied in the article, that they must use a massive 1024-bit cipher key — I’ve just logged into the Commonwealth Bank’s site, and all is working fine with their 256 bit key.
While Citylink/Transurban might be whinging that they’ve done nothing wrong, given all the other secure sites I use with Chrome are working perfectly, the conclusion I come to is that indeed there is a misconfiguration on their end.
It’s important that they get this right. After all, one wouldn’t want personal information being transmitted insecurely. It could get picked up by a passing Google Streetview car doing packet sniffing!
Update 10:45am: The reference to MS-DOS has now been removed from the article, which now reads: an internet-infused operating system for computers that takes on Microsoft.
It also no longer says Only one browser was available… in 2000, but has been changed to say One browser was dominant.
That article is confusing. I cannot for the life of me figure out what point its actually trying to make. Chrome OS bad? Google vs Citylink? There’s even some stuff about Fairfax shares? I also doubt the referenced “security audit” had anything to do with security around a public-facing website. Its more likely to have to do with internal processes and such.
My understanding of SSL/TLS negotiation is limited, but here’s what I think is happening. When you start a secure connection, its necessary for the client and server to exchange key and certificate information so they can check who is on the other end and set up the encrypted channel. Obviously this information has to be exchanged in a secure way, otherwise a middleman could modify or replace that data causing one or both ends to wrongly trust the connection.
There’s a number of different ways that keys can be exchanged securely. One of those is Diffie-Hellman Ephemeral (DHE) mode which involves the two ends creating temporary keys and using them to set up a secure channel to pass the “proper” certificates and keys. My understanding is that part of the security of this comes from the fact that the temporary channel is only active for a small amount of time and so with suitably large temporary keys an attacker can never have the time to break the encryption before the channel is finished with and the “real” encrypted channel is set up.
If one of the temporary keys is too short, then there’s a risk that an attacker can break the channel before its finished with, allowing them to compromise the key exchange. This is what Chrome is complaining about.
The generation of the temporary keys is a function of the server (or more specifically, the security library eg OpenSSL). It has nothing to do with the public-facing certificate that you purchase from Thawte or Verisign or whoever. This is why its reported as a server misconfiguration.
The article also states that in the year 2000 there was only one internet browser. Internet Explorer. Clearly this writer has no clue!
@Rob N, ignore the bit about Fairfax shares. The print version is formatted to make it clear this is a completely separate issue; the web site formatting doesn’t make that very clear.
@Julian, yeah I noticed that too. Never heard of
NetspaceNetscape, obviously. Mind you, it looks like in 2000, IE dominated, with about 80% of the market.http://en.wikipedia.org/wiki/Usage_share_of_web_browsers#Older_reports
I think the bottom line here is that it’s dangerous to let business writers publish articles about IT issues without them first getting checked by an IT expert.
Daniel, web app security is my day job.
There are a couple of errors:
* They ask for your login and pin on an unencrypted page. Trivially fixable
* The login button link is not to an encrypted page. Trivially fixable
* According to Safari, the SSL certificate has only a 128 bit public key component, which is fairly feeble today.
The certificate expires next year, and honestly, for the $200 or so it would take to fix this issue, I’m surprised that they have been in discussions with Google since August instead of just fixing it.
I’m sure their security vendor Stratsec has told them what needs to be fixed. This is extraordinary that a simple and cheap fix has not been put into place.
In my personal opinion, anyone not using an Extended Validation certificate on a modern web server should not be able to handle credit card transactions. This is the minimum that folks taking credit cards should be doing today. It’s all about trust. It takes seconds to destroy trust and forever to build it up again. I can’t understand why they are procrastinating.
thanks,
Andrew
SSL works by agreeing on a session key using public-key cryptography (RSA/ECC) or Diffie-Hellman (DH) key agreement. The reason for that is that symmetric-key cryptography is far cheaper in terms of computational resources (4 or more orders of magnitude). When the article mentions 128/256 bits, (and years ago 40/56 bits, although that isn’t mentioned), that is the key size for the symmetric cipher. DH & RSA both rely on primes (that’s what the ‘less than 512 bits’ is about), and usual recommendations are for relatively large primes (300 digit prime minimum, which is approximately equivalent to 950 bits). The reason is that it is possible to brute-force the relevant mathematical problem (try out all the combinations and come up with the right one), and choosing larger primes increases the effort required to do so (in DH, every extra bit doubles the computational effort required to break the lock).
In short, the problem with the author’s article is that he doesn’t understand the difference between the symmetric ciphers in use, and the asymmetric ciphers used to come up with the keying material for the symmetric cipher.
Changing the subject a little, can someone please confirm whether secure sites are secure between my computer and, say, the bank (for internet banking sites), or if they’re just secure between my ISP and the bank. In other words, are secure operations still secure for browsers on a corporate network that may be subject to various snooping and logging by an IT admininstrator?
Yep, secure connection from the web browser to the server. That’s the whole point, of course, to prevent packet sniffing along the way.
They also use a 4 digit unencrypted pin number as a password for your account. I would hate to be their lawyers after their database gets hacked.