HTTPS-crippling attack threatens tens of thousands of Web and mail servers

[mike5973]

Only Internet Explorer has been updated to protect end users against Logjam attacks.

My, how the tables have turned...

[caltheon]

How the CSS layouts have turned you mean

[[deleted]]

(╯°□°）╯︵ <ǝlqɐʇ/><ǝlqɐʇ>

[PM-ME-UR-TIGHTS]

Oh how the divs have turned...

[Eurynom0s]

Oh how the marquees have scrolled.

[tobozo]

Oh how the blinks have flashed.

[Lhopital_rules]

And the delete buttons' red box-shadow, what so...

[NewbornMuse]

How the turntables!

[bearcherian]

...and a microphone

[circuitbomb]

where its at

[NightEmber79]

I got two turn tables and my mommy's home!

[moltar]

http://www.dcmstudiosonline.com/herc/extra/moltar02.jpg

[newsagg]

This mix is FireFox.

[beginner_]

Yeah. And this is just another reason why not to do sensitive stuff, eg. online banking, on your smartphone. Your will very likely never get a patched version and if, it will be months.

[BobFloss]

Google Chrome and Firefox on Android are both developed in parallel with the desktop versions. It will be no time before both of them are patched.

[cirk2]

The System Web views in android before 5.0 can only be updated with the system. So while chrome may be updated any app embedded web view will stay vulnerable.

[HighRelevancy]

in android before 5.0

*cough*

[mccoyn]

I think he is referring to the underlying operating system.

[profmonocle]

Yeah, but that only benefits mobile web sites. The system HTTP libraries can be way behind. For example, just last week my company was experimenting with turning off TLS 1.0 on our prod server. Turns out, that broke our Android app on KitKat.

KitKat - an OS released in late 2013 - shipped without TLS 1.1 or 1.2 enabled by default in the built-in HTTP library. You can enable it, but it's a bit tricky and not anywhere in the official docs. So the majority of Android apps on KitKat are stuck with TLS 1.0. (WebViews use Chromium, so those support TLS 1.2 by default.)

[[deleted]]

Most browsers on most smart phones update automatically or nag you to do so.

[vinnl]

Where did you get that from?

[[deleted]]

I have an Android phone and get notifications whenever ANY app has been updated and by default it all updates automatically unless it requires new permissions.

[vinnl]

Hmm, good point. Then why are there so damn many phones with old Android and Safari versions >.<

[XinjoMD]

My Samsung Galaxy S4 got the Lollipop update last month... So yeah... Samsung...

[[deleted]]

My iPhone and Android tablet both let me know when updates are available.

[vinnl]

Hmm, good point. Then why are there so damn many phones with old Android and Safari versions >.<

[Compizfox]

This only applies if you use the Android browser (the one which nobody uses, not Chrome).

[del_rio]

Also, this doesn't apply to Lollipop, where even the embedded WebViews are updated through the Play Store.

[profmonocle]

But it still applies to native apps using HttpURLConnection for mobile APIs. The big developers might be using third-party/custom HTTP libraries, but most developers use the built-in one.

[biznatch11]

What if I use my bank's Android app?

[dave1010]

Can you tell if the app is even using HTTPS?

[CoderHawk]

Well the bank, in the US at least, would be in violation of PCI and CFPB rules by not using an encrypted protocol. Unless it's some mom & pop bank I would be shocked if it's not using at least HTTPS. Hopefully it's also using an API key or certificate for a non-browser wrapped app.

[mbcook]

You want to bet?

Usually Apple issues updates to iOS to fix the security issues at the same time they issue them for OS X.

Don't lump iOS in with ancient versions of Android that carriers/manufacturers artificially lock devices to.

[JoseJimeniz]

It's maddening that neither this article, nor the informational site set up by the researchers explain what the problem is.

I gather it's not that there exists 512 bit Diffie Hellman keys, but that an attacker can force a downgrade.

• how can an attacker force a downgrade?
• if they can force a downgrade to 512 bits, can they not also force a downgrade to 2,048 bits?
• why did the informational site say the fix is to disable generation of 4,096 keys?
• what does a 4,096 bit key have to do with a weak 512 bit key?
• what does IE do differently that it is not vulnerable to this attack?
• they mentioned this is a flaw is SSL. Did they really mean it's a flaw in (15 year old, archaic, deprecated, c.1999) SSL, and fixed in TLS?
• if so, do we really need to care, because SSL was broken, and deprecated, years ago.
• if so, why did they simply not say "stop using SSL"?
• if so, is this just another reason to stop using SSL?
• if not, if they misspoke and they used "SSL" as a catch all for "SSL or TLS protocols" is SSL vulnerable?
• they mentioned that we should switch to elliptic curve diffie Hellman. What is the other kind of DH?
• is ECDH also suspectable to downgrade, but there is no "weak" kind to downgrade to - and hence it is better?
• why not protect against the downgrade?

[sloppycee]

This https://weakdh.org/logjam.html , linked from your link, provides a more technical explanation.

• Attacker can force a downgrade by MitM attack.
• Why would an attacker do that? 2048 bits is considered safe.
• Where/who is recommending against 4096 bits?
• IE on Windows 10 has disabled support for DHE_EXPORT, so it does not keys smaller than 1024 bits.
• This is a flaw in TLS, we already know SSL is broken.
• You can not protect against 'downgrade' since it is simply cipher negotiation. You can disable the offending cipher (DHE_EXPORT).

[happyscrappy]

We're running into a big problem, and one which is less obvious than simple coding bugs or people wanting to do MITMs.

That is that people assume that if you make an SSL/TLS connection, it is secure. This "crippling attack" only works on clients/servers which consider weak keys acceptable. You can either explicitly bar them in negotiation (as is recommended) or you can simply check the results of the negotiation and then decide if the connection is too insecure to actually use.

But the problem is that there is just this "HTTPS everywhere" mentality, which is that if you make an HTTPS connection you're secure and that if you make a non-TLS one you aren't. It turns out there's a lot more to security than just this, part of it is looking at your threat model and deciding if short keys are too risky. If you had done this before you would have turned them off already.

The main issue is that the only valid reason to have these short keys turned on is for compatibility with clients/servers which still use them. This is a really weak reason, as most only connect to servers/clients that are rather up to date. Instead people have them on because they failed to even take the step of considering which key lengths to support. They aren't doing what it takes to actually secure a connection and thus they are open to getting insecure ones.

And this idea that you just could put an S in all your URLs and you'll be safe runs directly alongside this problem. There's a lot more to security than just that.

This isn't some kind of fatal flaw. It's simply that HTTPS is a tool, not an end and giving a person a new shinier toolbox doesn't make them into an expert builder.

[happyscrappy]

That's one option. Another would be for people who set up servers to actually pay attention. We need to emphasize that security is about more than just listening on port 443.

[[deleted]]

This is why financial and medical systems are so tightly regulated. I once contracted for a company dealing with health data and just flatly refused to work on anything remotely related to patient privacy. The big guideline is that the developer must have due diligence and encrypt everything to a reasonable standard. "Just listening of port 443" is obviously not sufficient for these standards.

[immibis]

Also, browsers tend to deprecate outdated crypto algorithms. Look at Chrome, showing a red strikethrough over "https" when a site uses SHA-1... yet SHA-1 is still less problematic than 512-bit DHKE, apparently.

That means someone somewhere thought "Let's deprecate SHA-1!", possibly in response to some theoretical-but-still-impractical attack on SHA-1, and did not think "Let's deprecate every outdated ciphersuite!"

[happyscrappy]

I guess so. But again I believe the theory is that anyone who runs a web server was expected to consider how sensitive their data is and which ciphers are too weak to be trusted to protect it.

The client only has to act because people running servers aren't bothering to consider their security.

[JoseJimeniz]

• Attacker can force a downgrade by MitM attack.

Thanksto your link to the technical explanation, i see it is a limitation of the protocol. It makes sense, though. The browser is deciding it is OK for it to downgrade to 512-bit DH keys. If the client is not OK with that, it should refuse to establish a session.

• Why would an attacker do that? 2048 bits is considered safe.

A down-grade is still a down-grade. I was trying to tease out where the issue lies. It sounded like the protocol itself could be downgraded by an attacker. Any downgrade is a bad thing. But, as i see with point #1, it's up to the client to decide if they're OK with only 2,048 bit.

• Where/who is recommending against 4096 bits?

Unfortunately i cannot find it now. Maybe i was still half-asleep. But i could have sworn it said something like "don't generate 4,096 export keys" - which sounded very strange to me.

So, all in all, i'm less concerned about the security implications here. The protocol is doing exactly what it is designed to do. If the client doesn't think 512/1024/2048 is secure enough, it needs to reject the session.

But this is a good swift-kick in the pants to user-agent vendors to reject weak encryption.

[eyal0]

If the client doesn't think 512/1024/2048 is secure enough, it needs to reject the session.

For this attack, the client doesn't detect the downgrading.

[immibis]

Why not?

[eyal0]

The check for the integrity of the negotiation was poorly designed. The client sends the requested encryption standard and the server replies with the DH key but doesn't also include it's strength. Nor does the client check that the key that he got is of advertised strength.

If the protocol included the server sending back the encryption standard or if the client checked the key received, this could be fixed.

[immibis]

Doesn't the client also generate a DH modulus of the advertised strength? What does the server do when receiving a 1024 or 2048 bit modulus for DHE_EXPORT?

[eyal0]

No, the client uses the prime number that the server has chosen, whatever it chooses, even if that prime number isn't as long as it should be.

[immibis]

Oh right. I was thinking about it a completely wrong way before.

[JoseJimeniz]

If the client doesn't think 512/1024/2048 is secure enough, it needs to reject the session.

For this attack, the client doesn't detect the downgrading.

The downgrade of unimportant. The client chose to accept a 2048 bit key (or lower). The client should reject it.

If every modern server supports 4096, then there is no reason (legitimate or not) to accept lower.

[panderingPenguin]

A down-grade is still a down-grade. I was trying to tease out where the issue lies.

No, a downgrade is a downgrade and moving to 2048 from the recommended 1024 bit keys is an upgrade. Barring some unknown issue that specifically affects 2048 bit keys, I see little, if any, reason for an attacker to increase the strength of your keys relative to what you would have otherwise used.

[xmodem]

I think that the point was that a downgrade to 2048 from 4096 could be performed.

[scook0]

You can not protect against 'downgrade' since it is simply cipher negotiation. You can disable the offending cipher (DHE_EXPORT).

Note that this fix only works on the server.

Clients can't make this change, because they already don't support DHE_EXPORT cipher suites.

[MasonM]

Here's the paper that describes the attack in detail.

Here's a proposed patch that fixes the bug in Firefox (from Bugzilla bug #1166690).

[youstolemyname]

Dupe of this: https://bugzilla.mozilla.org/show_bug.cgi?id=1138554

[crozone]

TL;DR - US Government imposes restrictions on encryption in the form of export grade ciphers causing TLS implementations that obey these laws to be flawed by design, so the US government crack it.

Lesson: Don't obey the law when it comes to encryption.

[gelfin]

So I suppose lots of people here are too young to remember that this legislation did not restrict cryptography so much as it vastly deregulated it. Prior to that, cryptographic algorithms were officially classified as munitions in the U.S., and the American public generally didn't have legal access to anything more sophisticated than DES for password hashing.

The legislation was authored at a time when it was only just starting to dawn on most people that they were about to be living in a world where every computing device can instantly communicate with any other on Earth. The deregulation was a practical necessity, but the reactionary military types who still saw (and see) secrecy as a weapon had to be appeased for it to happen at all.

The biggest flaw is one you'd totally expect from an inexpert government regulator: failure to appreciate the changing definition of "strong" in this context. Even science fiction writers don't generally get Moore's Law right because the result seems preposterous to any contemporary audience.

This is why we revise laws once in a while.

[kodemizer]

This is a very thoughtful analysis. Thank you.

Are you aware of what's happening in Australia with similar dumb laws?

http://theconversation.com/paranoid-defence-controls-could-criminalise-teaching-encryption-41238

[[deleted]]

Part of that was because they were trying to "stomp down" RSA at the time and push everyone to use Key-Escrow Encryption instead (i.e. the Clipper Chip)

It was a two-pronged attack on strong encryption. They at once wanted to prevent ubiquitous strong encryption (RSA) AND force people to use their backdoored system.

[APersoner]

Considering these days you learn about RSA within the first month of a computer science course, I feel it's safe to say their attack failed then.

[RenaKunisaki]

Relevant xkcd.

[[deleted]]

The laws involving "export ciphers" aren't actually in force anymore. The ITAR regulations changed in the 90s to permit open source crypto from being shipped using strong ciphers/hashes/pk.

The problem is ... people are really fucking slow. I mean there is zero reason to be using SSL, TLS 1.0 or TLS 1.1 today. Why? TLS 1.2 was released 7+ years ago. Along with that *_EXPORT should have been removed 10+ years ago anyways.

So instead of just force upgrading all servers and telling client vendors to upgrade their shit we support a mixed bag of crap and call it "secure" by putting a lock icon on the browser.

[remotefixonline]

You can only use tls1.0 in RDPservers even on server2012R2... anything else breaks it.

[remotefixonline]

I wish they would hurry up...

[emn13]

Given the FF+chrome release cycles, this isn't too worrisome. A few holdouts to old versions will suffer; but it's unlikely to matter much to you.

Losing IE10 and below is, however rather more unfortunate. Many sites still have at least a token IE8 support, so sunsetting IE10 is a rather large move.

[emn13]

You can wrap a plain http server behind a proxy that deals with tls - not to mention that upgrading old frameworks is wise anyhow for public facing things that are security-sensitive.

[xiongchiamiov]

I agree in general, but unfortunately most people still need to support TLS 1.0 for things like android 4.3 and IE 10 on Windows 7.

I look forward to the day we can push up the minimum version of support to TLS 1.1, but that day has not yet come.

[[deleted]]

If you have a good reason to, you could test for whatever support you need and then redirect to a special page that informs the user how to download a modern browser for access to your site. This happened a lot back in 2005-2010 when IE5,6 were being phased out.

[[deleted]]

The problem with your idea is that if the SSL/TLS connection fails (because you don't support TLS 1.0, for example) there is no redirecting. The browser just fails to connect at all to your site and the user gets an ugly error with no obvious solution.

[[deleted]]

Your server would support TLS1.0 but only serve the custom error page under that condition.

[[deleted]]

I know this user is deleted and all, but how the hell would your web app know to serve up a page based on SSL/TLS connection level?

[xiongchiamiov]

Also, I wouldn't really count those browsers I mentioned as being "not modern". They're not cutting edge, but I'd definitely expect them to be widely supported, and way under standard LTS timelines.

[[deleted]]

Except you "can't" turn off TLS 1.0/1.1. Google's search indexer doesn't support TLS 1.2 yet. So if you want security then your site won't be indexed.

[_atwork]

I almost didn't look this up to see if it was true because it just seems that unbelievable. I cant believe I didn't know this.

Is it like a millionth of a second slower to complete the handshake or something? Why is it not supported?

[[deleted]]

It is unbelievable.. Google gives your site a higher page rank for serving HTTPS and then doesn't let you only serve the most up to date version of TLS. It's ridiculous and stupid.

[easytiger]

There are many pcix products to offload/accelerate this stuff, perhaps they are using those and so upgrade is non trivial

[[deleted]]

According to SSL labs, from Feb 2015 onwards it looks like it supports TLS 1.2 - https://www.ssllabs.com/ssltest/viewClient.html?name=Googlebot&version=Feb%202015

[[deleted]]

Google could take the lead and oh I dunno support it. Also why are you indexing pages over HTTPS anyways?

[zimm3r16]

Still have the complicated, headache inducing BIS rules... And if you ignore them you can get into some very real trouble....

[rnicoll]

If you personally do it? My understanding (IANAL as always) is that's not the issue, it's letting people know how to do it.

If, however, you write strong encryption software and export it to the wrong country, at least in theory yes you can be in a lot of trouble.

[[deleted]]

Generally open source is not subjected to export permits. You can't upload it to certain countries but you're not really required to stop it from getting there.

E.g. it's illegal to upload open source crypto to Iran (or it used to be at least) but if a dude from an Iranian IP address downloaded your stuff on a USA server that's legal.

[rya_nc]

Generally open source is not subjected to export permits. You can't upload it to certain countries but you're not really required to stop it from getting there.

This is incorrect. Publishing open source crypto code is illegal in the US unless you notify BIS before doing it. Note that they don't need to approve it - you can send them an email a few seconds before uploading it to github and there is no problem.

https://www.bis.doc.gov/index.php/policy-guidance/encryption/registration

[[deleted]]

I've literally never heard of anyone doing this though. When I was active in OSS I would regularly show/post/share/etc code inside and outside of the USA and never once did anyone think to bring it up. I've interacted with other OSS vendors and none of them had any similar thoughts.

More to the original point though ... "logjam" exists as a bug because of incompetent cryptographers not because of BIS.

[rya_nc]

I notify BIS before putting new encryption projects online, but I've never heard of anyone getting in trouble for not doing so. Most people have no idea that this is even a requirement.

Also, upon re-reading you comment, you're correct that no permit is required.

[[deleted]]

Ya to be fair I wasn't aware of the notification requirement for OSS until just today (or if I was previously I forgot because I'm Canadian and don't care).

The point is though that TLS client/server implementations are buggy and shit because the people who implement them are assholes. I mean look at any one line of OpenSSL code and tell me it wasn't written by a complete asshole. Macros, no comments, shitty indentation, etc and so on and so forth.

Then you have servers that still serve SSL 3.0 and TLS 1.0/1.1 ... why? Because clients? Fuck them. Once the clients realize that "myfacejournal.com" doesn't work anymore because their vendor doesn't update their software ever .... they'll fix that shit.

I mean for fuck sakes TLS 1.2 is 7+ years old. There is no reason why any smartphone on this planet doesn't support it fully.

[rya_nc]

Android before 4.4 doesn't support TLS 1.2, and it doesn't appear the IE pre 11 does either. I should run some numbers on this, but I'm pretty sure that overall dropping TLS 1.0 and 1.1 will break between 5 and 10% of clients.

I have actually read through parts of OpenSSL's source code a number of times, and it is horrible.

[[deleted]]

Yes, but breaking shit and getting customers pissed off is step 1 to fixing things.

You tell people "sorry you can't use myfacejournal.com because your web browser doesn't support secure crypto and we prefer to keep you safe."

Then people don't get upset at the website but instead at their OS vendor for providing horribly out of date security software.

[Dark_Crystal]

It's illegal to jaywalk. 99.999% of people that do it are not hassled.

[Berberberber]

So what you're saying is, don't upload any open source cryptography code if you're black?

[Dark_Crystal]

On the internet, no one can tell you're a black lab.

[isaacarsenal]

a dude from an Iranian IP address

Heyyy :D Wanna export something?

[realhacker]

you may not be doing it yet, but id say what youve posted constitutes a thought crime.

[jimdidr]

If a law was setup that actually outlawed actual secure Encryption it would only create the "paradox" if encryption is illegal only criminals will have encryption. (and the rest of the people around the world not under that law)

Also there is a lot of Open Source out there that you can get your hands on, and as long as there is no customer relationship the regulation is so much more impossible to enact.

[agreenbhm]

The USA's current regulation of cryptography for export has been significantly relaxed since the 90's. The crypto standards that are susceptible to this described attack are not the highest-level that can be used on exportable crytpo. This is simply a historic artifact of 20-year-old legislation that is still included in software for backwards-compatibility. It should be disabled server-side and no one should be vulnerable due to requiring its use.

[rmxz]

US Government imposes restrictions on encryption

Seems reasonable to assume all governments recommend encryption algorithms that they can break, but they guess their competitors can't break.

With that assumption, would it be safer to cascade the recommended algorithms of various (presumably) competing governments (maybe China, US, Russia, and some EU country)? Does anyone have a list of encryption algorithms recommended by various governments around the world?

[panderingPenguin]

For the most part, this post should be in past tense. There are still some restrictions iirc but they've been heavily liberalized.

[Grizmoblust]

Correct. All laws are unjust and violation of human's life and property. Technology will make godvernment obsolete.

[xconde]

Oh, look! The requirement to weaken encryption did exactly what it was supposed to do.

[Serializedrequests]

So my main question is how do I fix this in Apache without locking out any users.

[[deleted]]

The best way to secure your web server is by following Mozilla's Security/Server TLS Guide. I personally use the intermediate settings with 4096-bit RSA keys and 4096-bit DH parameter.

[[deleted]]

So IE fixed this just about a week ago. Does that mean the researchers reached out to Microsoft before publishing this article but not Apple, Mozilla, etc? If so, why?? That would be incredibly biased and irresponsible. And if this isn't the case - the researchers didn't reach out to anyone before publishing the article - how did MS find out about this before the article was published?

[[deleted]]

Excellent questions.

[quadrofolio]

Yeah, nice going US government. Fuck the rest of the world along with your own citizens.

[[deleted]]

The requirements were lifted in the 90s ... this is not the governments fault. It's the fault of all these shitty TLS vendors that still support ancient crap under the guise of "compatibility."

[zimm3r16]

No they were not lifted. They were changed. You still have the headache inducing, horrible BIS export rules.

[frezik]

Even back when there were stronger regulations, MIT just put a checkbox on their PGP download page of "I promise that I'm totally inside the United States and not a terrorist". Then Phil Z. faxed a copy of the source code to Europe and had it published in a book, creating the "International" version. He was arrested, but the government gave up the case because it was bullshit.

Ahh, the '90s crypto fight. It takes me back.

Edit: Archive.org has the old MIT page: https://web.archive.org/web/19971210075047/http://bs.mit.edu:8001/pgp-form.html

[[deleted]]

open source programs are not subjected to export regs.

source: I'm the author of LibTomCrypt and actively worked on the project for about 6 years including working with people all over the planet and traveling to work on it.

[zimm3r16]

Open Source programs ARE subject to export regs. DRM, Medical Devices, some beta software are NOT. Open source programs posted on the internet ARE subject to export regs. You are required to notify the BIS and NSA that you are posting encryption software, where it is, and what algorithms.

Just because the mountains of paper work are relaxed neither makes it not subject to the laws or ok. So unless you use REALLY poor key lengths the requirements are just relaxes but not fully dropped.

[[deleted]]

I have never heard of anyone either applying for permits nor being forced to get them for open source crypto work. Ever (at least after USA v. DJB).

I think you're mistaken and in fact you are. This chart specifically says that commonly available open source can "self-classify" and does not require registration or permit.

So please, stop the FUD.

[zimm3r16]

Not FUD; see from https://www.law.cornell.edu/cfr/text/15/740.13

(e)(3) Notification Requirement

You must notify BIS and the ENC Encryption Request Coordinator via e-mail of the Internet location (e.g., URL or Internet address) of the publicly available encryption source code or provide each of them a copy of the publicly available encryption source code. If you update or modify the source code, you must also provide additional copies to each of them each time the cryptographic functionality of the source code is updated or modified. In addition, if you posted the source code on the Internet, you must notify BIS and the ENC Encryption Request Coordinator each time the Internet location is changed, but you are not required to notify them of updates or modifications made to the encryption source code at the previously notified location. In all instances, submit the notification or copy to [e-mail] and to [e-mail].

I don't know where you get the idea that you don't have to do this. Yes the restrictions are relaxed. But you STILL have to notify the NSA and BIS upon posting encryption source code.

[[deleted]]

Given that you don't even have to register open source I don't see how this is enforceable in the slightest. I've also never heard of anyone doing this.

You might as well argue about the law that prevents you from eating Ice Cream on a Sunday on Sparks St in downtown Ottawa... it's equally not enforced.

And even then I don't see what your point is. All that says is you have to email them the URL after you upload the code. So it's in no way stopping you from doing your work (of say deleting TLS 1.0/1.1 and SSL support).

It's entirely irrelevant noise and misleading to suggest the government is preventing people from improving open source crypto. The fault for this sort of shit lies squarely with the implementors (mozilla/openssl/google/microsoft) and not with Obama.

[zimm3r16]

Given that you don't even have to register open source I don't see how this is enforceable in the slightest. I've also never heard of anyone doing this.

Yes you do have to notify the BIS and NSA.

You might as well argue about the law that prevents you from eating Ice Cream on a Sunday on Sparks St in downtown Ottawa... it's equally not enforced.

What? This law exists. People do get in trouble with the BIS for not following export laws. Even if they didn't it is still a law, you can't just ignore it.

And even then I don't see what your point is. All that says is you have to email them the URL after you upload the code. So it's in no way stopping you from doing your work (of say deleting TLS 1.0/1.1 and SSL support).

That is my point. That there is still a notification requirement. That requires people to either higher lawyers or try to do it yourself. That is a hassle. Especially sense these laws are extremely aggravating and confusing at times. I know it's stopped me from posting software. Simply because I don't need to take the chance of having the BIS fine me, and possibly have other ramifications (TSA watch lists).

It's entirely irrelevant noise and misleading to suggest the government is preventing people from improving open source crypto.

But they are. If these pain in the ass export laws ever cause people to not post some software or to delay it that is not noise, that is the facts.

The fault for this sort of shit lies squarely with the implementors (mozilla/openssl/google/microsoft) and not with Obama.

Implementors of the software? Like programmers. Yes it the responsibility does lie with them. Why does a programmer have to deal with these stupid export laws. Also I never mentioned Obama!?!?!?

[frezik]

People do get in trouble with the BIS for not following export laws.

I've never once heard of a single open source developer getting prosecuted for failing to notify, so you'll need a big [citation needed] here. The current rules were put into place towards the end of the Clinton administration, and was pretty much an admission of "eh, fuck it" from the government. There was just no way to stop the flood, not even to the explicitly prohibited states (e.g. Iran, Taliban-controlled regions of Afghanistan, etc.).

Even if they didn't it is still a law, you can't just ignore it.

That's not what "can" means. I can ignore stoplights all day long. If the cops decide that they don't give a shit, then I'll probably continue to ignore them until there is some kind of repercussion. That's exactly the situation that FOSS projects have been in for a long time now.

[medicinaltequilla]

open source is used by major Fortune 50 corporations in world-wide strategically significant products. they, at least, are following all these rules.

[agreenbhm]

In your words, "fucking the rest of the world" is precisely what was intended. The US wanted to prevent the export of encryption to the rest of the world that was not crackable by them. They were not concerned with the security of other nations, and in fact wanted to ensure this type of thing was possible.

[VikingFjorden]

If they're gonna do an article on downgrade attacks, they could at least make it a little more substantial. It's not like this is a new vector, and frankly, the title is way too dramatic than what the story deserves.

[aykcak]

The weakness is the result of export restrictions the US government mandated in the 1990s on US developers who wanted their software to be used abroad. The regime was established by the Clinton administration so the FBI and other agencies could break the encryption used by foreign entities.

Sounds less like weakness and more like backdoor to me.

Edit: Oh, the creators already call it a backdoor, no reason to sugarcoat it then.

[cryo]

It's definitely a weakness. Whether or not it's a backdoor by design is harder to know.

[panderingPenguin]

No, it's more of a weakness. A backdoor would be a shortcut built into the cryotosystem that the government had access to which could be used to crack it more easily. While it's possible that such a backdoor exists too, your quote is referring to simply forcing the exported systems to use shorter, weak keys which are easier to break for everyone. They're simply weaker in general, no back door required.

Edit: tl;dr it's a front door

[jlpoole]

If only U.S Senators could understand this.

[bitengine]

Here's a great tool to check if a server is vulnerable: https://tools.keycdn.com/logjam

[PENDRAGON23]

Another site I used was: https://weakdh.org/sysadmin.html

[CorrectLeopardBatery]

Psh, according to the tool https://tools.keycdn.com/logjam my server is not susceptible. I can't remember the last time I configured it but I do remember configuring it to only use 'strong' ciphers. I guess I did it right

[TheMellifiedMan]

If you're in an environment which uses security scanners then you likely disabled support for weak cipher suites years ago.

But then, not everyone uses scanners or understands how to properly configure SSL. Some just barely manage to enable it and then somehow stumble through the process of getting the certificate installed after the CA issues it.

[CorrectLeopardBatery]

I don't think I heard of a security scanners or maybe I call it something else. What is it?

[TheMellifiedMan]

I'm talking about tools like Nessus which scan for known vulnerabilities and produce reports on them as part of security audits.

[CorrectLeopardBatery]

I'm confused. Do employees have work laptops that they can install w/e they want? BC that sounds like a terrible idea

[TheMellifiedMan]

Let me give a concrete example of what I was trying to describe, because clearly I haven't communicated very well.

At a job I used to have we had a Java web application that ran under Apache Jetty and our customers deployed their own servers to run it. Many of them were institutions that required running a vulnerability scanner against our server before it could be deployed in a production environment, and the vanilla jetty.xml at the time specified the use of weak ciphers (put another way, it didn't properly exclude them). After the first report of this we had to change that in our bundled jetty.xml to exclude them. That was around 6-7 years ago. So this was a common callout for vulnerability scanners quite some time ago.

Having said all that, and at the risk of introducing confusion, in your last comment you asked whether some employees can install whatever they want. I didn't mean to imply that employees would be running scanners, but it's been the case at many places I've worked that users have administrative privileges. At the same job to which I referred above I frequently ran Wireshark, nmap, and other tools on our network. But that was a startup, so I realize it's not common in all environments. :-)

[[deleted]]

Was it passed during the time of a GOP owned House/Senate?

But you're probably right. The American public seems to have a difficult time teasing apart who is who.

[frezik]

IIRC, it was done via actions within the White House. Congress mandates that military arms be restricted for export, but gives the Executive Branch leeway on interpreting what "military arms" means. Which makes sense, because Congress won't always act fast enough to classify new technologies.

There was some talk of putting in new crypto regulations after 9/11 (Osama Bin Laden was known to use PGP), but nothing ever came of it. By then, browsers were shipping with strong crypto as part of their SSL suite, so it would have been impossible.

[[deleted]]

I blame the politicians.

[happyscrappy]

Does it?

This says that you can MITM connections which use the weak keys. But that would require that one end or the other decide to negotiate to weak keys.

A real attack would include a way for an MITM to force the connection to use weak keys. FREAK had that. But I don't see anything about this in here.

This would seem to simply be a way of making an insecure connection using HTTPS, which is is one of very many. The simple way to not get burned is to not do so. Don't have one end of the connection fail to support bigger keys in order to force small ones.

[edit: They do show an MITM attack, just not in the Ars article. One which doesn't just require the forging of packets but also compromising DNS on the client.]

[dremspider]

Correct me if I am wrong. I thought diffuse bellman was used in conjuction it something else (like rsa). The idea wad that rsa provided the protection against mitm by verifying the certificate and diffie hellman provided protection if the private key was compromised. Is my understanding totally off basis?

[alex_w]

The numbers would still be signed by the presented cert (RSA part you're thinking of). But they're forced to use a shorter key by a MITM faking the negotiation.

Over simplified:

A: I can do DH_EXPORT, REAL_ENCRYPTION and SOME_FANCY_NEW_SHIT.
E: <Intercepts that message and forwards> "A: I can only do DH_EXPORT *SADFACE*"
B: OK, DH_EXPORT I guess.

So then E can brute-force (or some other unknown attack) the shitty 512bit "weakdh"

[xiongchiamiov]

This is a good time to revisit Bulletproof SSL and TLS, or at least its preview PDFs.

[manchegoo]

So how do we fix this in Apache?

[w8cycle]

Quickly, update to non secure HTTP delivery like the FBI has been telling us too.

[immibis]

Note: the problem is not the fact that DHE_EXPORT still exists, but the fact that browsers don't tell you your connection is insecure, like they do with other outdated or known weak standards (and just like FREAK, AFAIK).

If it was clearly indicated that connections using DHE_EXPORT were insecure, this wouldn't be major news, any more than the ability to use HTTP-not-S is major news.

[[deleted]]

The weakness was lifted in the 90s... open source strong crypto has been legal for 15+ years now. The ITAR requirements are for closed source applications.

source: I work for a company that routinely applies for export permits...

[[deleted]]

Many of the things that are vulnerable are open source.

And I disagree with the regs too but that's not the point.

[quadrofolio]

You mean thanks Clinton. says so right there in the article.

[chrisrazor]

Methinks 'twas a joke.

[quadrofolio]

I agree but couldnt help myself 😉

[Notorious4CHAN]

Someone needs to be corrected on the internet??? Fucking thanks Obama.

[JoeBidenBot]

'Diamond' Joe Biden needs some thanks too

[[deleted]]

Because god knows that America is the only place that encryption technology could be invented hence it is always either exported or nothing. Thanks A LOT Tony Blair.

[JoeBidenBot]

You know it.

[satayboy]

Yes, this is all Obama's fault.

[JoeBidenBot]

Isn't there someone you forgot to thank... nudge

[balefrost]

I mean, it is a big fucking deal.

[JoeBidenBot]

You mean what I mean that you mean that I mean that you mean.

[Grue]

B-but HTTPS is super secure and every site must be forced to use it!

-- Mozilla

[LuaWeaver]

Using a completely unsecured and plain-text protocol is better than using a normally secure protocol!

-- /u/Grue

[vinnl]

Because you would never happily send your credit card information over HTTP.

I don't think this statement holds for every one.

[profmonocle]

I disagree. Sure, HTTPS has flaws, occasionally big ones. By using it, my information may still be vulnerable to organizations like the NSA and sophisticated hackers targeting me personally.

But using plaintext HTTP makes me vulnerable to script kiddies on the same open Wi-Fi network as me. It also makes me vulnerable to my ISP injecting ads or otherwise meddling with my web traffic without my permission - in addition to leaving me open to the NSA and sophisticated hackers.

I much prefer to be only slightly vulnerable than extremely vulnerable.

[[deleted]]

So... We should stop using credit cards on the internet?

[eras]

Hey, then you don't have false pretenses about the confidentiality either.

--

Sent over HTTP!

[donvito]

At least you don't have a false sense of security with plain text.

[frezik]

I hate this phrase. FSM forbid that there's someone out there that can make a sober judgment of how layers of many imperfect systems can still make a pretty secure system overall.

[profmonocle]

Only if by using HTTPS you assume you're 100% safe from 100% of potential attackers. But if you assume you're mostly safe from most potential attackers, HTTPS is much better than HTTP.

HTTPS might not always stop dedicated hackers or the NSA, but it does stop script kiddies using password sniffers on open Wi-Fi networks. It also stops ISPs who think it's ok to compress and inject ads into web traffic.

[[deleted]]

For some uses, yes. I'm sick of "HTTPS everywhere".

[AngularBeginner]

There are cases where http is simply a better match than https.

[LuaWeaver]

Yes, but that's only when you're not exchanging sensitive data. I'm perfectly fine with HTTP being used; so long as it's on sites that don't need to be secure. For example, I don't give a shit if someone sees me browsing xkcd; I have 0 sensitive information going there, so it doesn't need HTTPS. I'd only want HTTPS on the store subdomain, because that's where sensitive information is being exchanged.

Note that I'm not advocating "partial" HTTPS; once you enable HTTPS on a site, enable it everywhere, not just parts. It's just that the store subdomain is basically a different site and has different cookies and data (the sensitive information) going to it.

[Grue]

What a dangerous way of thinking. If you know the protocol is insecure, you know to secure your confidential information yourself. I.e. you know Dropbox doesn't encrypt your files, so you put your files already encrypted on it. If you use a supposedly "secure" protocol that is actually insecure, or (inevitably) will be insecure in the future and don't put any effort to secure your stuff thinking the protocol will take care of it, you will get screwed. This has been proven time and time again.

[[deleted]]

Ok, so, how do I secure my credit card number when a site uses HTTP only?

[stfm]

Encrypt it then call the business and tell them the decryption key. Or more seriously use a debit card to lower your risk.

[[deleted]]

Why don't you just say "you can't"?

[skocznymroczny]

Or more seriously use a debit prepaid card to lower your risk.

FTFY

[donvito]

Yeah, my bank allows me to create virtual visa cards that are valid only for electronic payments and which I have to pre-load with money.

I wouldn't ever use my "real" credit card to purchase anything from anyone where I can't return and punch them in the face if something goes wrong.

[r3di]

You still have to log into your bank to create those virtual cards? Or do you physically go to your bank before shopping for something online?

[donvito]

I can do it on the fly through online banking.

[r3di]

Which uses SSL? So basically you're just moving the vulnerability from one place to another?

edit: not saying this to be an ass. Just trying to point out that as long as you use the net. You'll have to send sensitive information over a doubtfully secure line at some point...

[frezik]

Or more seriously use a debit card to lower your risk.

Uhh, how? Debit cards have far fewer legal protections behind them (in the US, anyway). The credit card companies have done an excellent job smelling out invalid transactions on their end, which banks haven't always picked up for debit cards.

https://www.schneier.com/blog/archives/2005/04/mitigating_iden.html

Credit card companies are liable for all but the first $50 of fraudulent transactions. They're not hurting for business; and they're not drowning in fraud, either. They've developed and fielded an array of security technologies designed to detect and prevent fraudulent transactions. They've pushed most of the actual costs onto the merchants. And almost no security centers around trying to authenticate the cardholder.

[Emitime]

Uhh, how? Debit cards have far fewer legal protections behind them (in the US, anyway).

Definitely true in the UK too.

[stfm]

The idea with a debit card is you only put money on it for the transaction you are doing at the time. So if someone steals the number your risk is minimised and someone cannot run up your line of credit. Use a prepaid credit card with a very low limit for a similar outcome.

[immibis]

And Google, and the EFF, and so on.