Many SSL websites still allow dangerously old ciphers.

[cooper]

It's being parrot around right now as the FREAK attack, which, somehow, is supposed to be the abbreviation of "Factoring attack on RSA-EXPORT Keys".

The short and sweet is that many SSL websites allow clients to downgrade the link encryption to levels dangerously close to plain text. In this particular instance researchers found they could downgrade to the old export-level encryption used curing the previous millennium - 40 bits. Breaking that takes a few hours, but since the keys remain in use for the lifetime of the server process chances are that's more than enough.

To test if this particular attack works against your machine, use this openssl command:

openssl s_client -connect your.machine.com:443 -cipher EXPORT

Some links on this:

http://threatpost.com/new-freak-attack-threatens-many-ssl-clients/111390

http://blog.cryptographyengineering.com/2015/03/attack-of-week-freak-or-factoring-nsa.html

http://www.zdnet.com/article/freak-another-day-another-serious-ssl-security-hole/

[digip]

Seeing the need more and more for on the fly, hands free SSL now? Things like this are probably trivial by law enforcement and government agencies that want access to data, not to mention the fact we know they've been actively weakening encryption means, from RSA to everything in between and wanting access to all VPN traffic(which they can already do anyway), it's time for building a better system, however we do it, there is a need; now just the how.

[cooper]

Well, the problem here is that when 2 parties want to communicate with confidence, both sides need 2 things:

1. A level of certainty that the other party is who they think it is.

2. A means of communicating that's safe from prying eyes.

The current solution to 1 is the Trusted Third Party, or TTP, which are the Comodo's, Verisigns, etc. of this world. It's their job to vouch for someone's identity. That's what you pay them for - to confirm to others that want to talk to you that you are indeed who you say you are. An alternative is the Web Of Trust concept which involves you going out there to find the people you want to communicate with and physically exchange public keys which you would register in your local address book as the verified address of SoAndSo. Alternatives are of course always welcome.

The solution to 2 is SSL where information provided and verified with 1 is used to determine a cryptographically secure session key unique to this communication session. To determine this, both sides must agree on a means to interact with one another which includes the crypto algorithm. The way they do this is to list to eachother what they support at which point the strongest algorithm both can work with is chosen. What is happening here is that admins, either through sheer laziness or because their PHB wants their servers to continue to support ancient crap like IE5, are allowing their servers to accept truly shitty crypto algs. This is the problem we're facing now, and the source of the problem is on both sides of the connection. When the other side wants to use ROT-13 for crypto, you disconnect.

From where I'm sitting, the plumbing is there. The need to trust a third party is the next best thing after exchanging keys in person. The crypto works. The concept behind deciding what crypto to use is decent aswell. Now if only programs would deny crypto that doesn't pass their personal sniff test and allow users to demand a specific minimum level of crypto to apply on top of that we'd be well on our way...

[overwraith]

Now if only programs would deny crypto that doesn't pass their personal sniff test and allow users to demand a specific minimum level of crypto to apply on top of that we'd be well on our way...

I don't see why it couldn't be done, isn't this already possible?

I know that the C# cryptographic classes allow if properly implemented to upgrade algorithms based on what Microsoft deems to be secure given their current information. Periodic updates to the .NET framework allow for this. Insecure algorithms will be programmatically deprecated. Now the servers might not be coded in C# .NET, but it is surely possible from a programmatic standpoint to implement such functionality in the web server whether it be IIS or other.

Edited March 5, 2015 by overwraith

[Jason Cooper]

It's not the technical issue that's the problem, shown by organisations that have private/internal websites and a specified minimum spec of web browser (e.g. their staff must use IE11+, Firefox v30+ or Chrome v35+). Then their internal websites have all the bad ciphers and weak versions of ssl disabled, and yet everything runs fine.

The problem is for all the public facing websites where not supporting an old browser will loose them users (and generally for those sites user=money). For those before dropping support for a browser, a cipher or protocol they have to wait till they have evidence that they aren't going to block access for a significant number of users.

Of course as a user you can always tell your browser not to use certain ciphers or protocols, which would protect yourself (e.g. to force TLS1 and above on Chrome you can use the parameter "--ssl-version-min=tls1")

[cooper]

Of course as a user you can always tell your browser not to use certain ciphers or protocols, which would protect yourself (e.g. to force TLS1 and above on Chrome you can use the parameter "--ssl-version-min=tls1")

Two problems with this:

1. How the hell are users expected to figure this out? 99% wouldn't know how to provide that parameter in the first place since they just click the colorful circle on their desktop.

2. A system-wide setting I would argue is insufficient. What I'd want is to be able to set a system-wide minimum where I can hand-pick which ciphers I'm comfortable with but where a general group like TLS1.2 can be used for the general public. On top of this, I want to be able to configure, on a per-site basis, what level I'm comfortable with. You could present users who want to configure this with a slide rule going from green to red w.r.t. the security level provided by the crypto (amount of bits, say) that shows what level is chosen now so you now have an idea of what the level currently is and you can fix that as being the low-bar for that site for any future traffic. So you know that when, say, your bank reduced its crypto level, you get some notification. When the crypto level offered by a site doesn't meet your criteria (either system-wide or site-specific, doesn't matter) that same slide rule could be presented showing the system-wide low-bar as one line, the site-specific line as am optional second bar and where on this slide the offered crypto would rank. If this rank is below the system-wide level, it won't allow you to connect. If it's between the system-wide low-bar and the site-specific bar, you're given the option to accept once, accept always (moving the site-specific bar down to that level) or refuse the connection, and the default (bigger and only green-colored button) is the latter.

The main feature I want is to be able to specifically deactivate a cipher, in case a problem is found with it. Say AES-256 was cracked tomorrow, how would you tell Chrome (or any other program for that matter) about this?

Edited March 5, 2015 by Cooper

[digip]

Spot check yourself: https://freakattack.com/

Most mobile devices, are vulnerable, not all desktop browsers are. My Opera 12 desktop, is not, my phone, is. (requires JS to be on to though)

Edited March 5, 2015 by digip

[Jason Cooper]

How the hell are users expected to figure this out? 99% wouldn't know how to provide that parameter in the first place since they just click the colorful circle on their desktop.

I wasn't suggesting it for every user, I was just pointing out that if you are worried about sites allowing weak versions of SSL/TLS then you can set your own minimum limit.

The main feature I want is to be able to specifically deactivate a cipher, in case a problem is found with it. Say AES-256 was cracked tomorrow, how would you tell Chrome (or any other program for that matter) about this?

you can use the "--cipher-suite-blacklist" parameter list the cipher suites you want to block (though I'll admit it ain't pretty and that you wouldn't want to use it if you can avoid it).

The best way I can see to tackle this problem for public websites will be from a different angle. That being the major search engines adjusting their rank algorithms to take the site's protocols settings into account (e.g. Site X ranks higher than Site Y because it was limited to supporting had TLS1.1 and above, while Site Y still supported SSLv3). In fact Google started taking https into account in their rankings last August, so if they push this factor a bit harder we may see more sites moving to https and getting their encryption up to scratch.

Edited March 5, 2015 by Jason Cooper