Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Hackers Break Browser SSL/TLS Encryption

Unknown Lamer posted more than 2 years ago | from the only-thoughtcriminals-use-encryption dept.

Encryption 110

First time accepted submitter CaVp writes with an article in The Register about an exploit that appears to affect all browsers and can decrypt an active TLS session. From the article: "Researchers have discovered a serious weakness in virtually all websites protected by the secure sockets layer protocol that allows attackers to silently decrypt data that's passing between a webserver and an end-user browser." A full disclosure is scheduled for Friday September 23rd at the Ekoparty conference. Note that this only affects SSL 2.0 and TLS 1.0; unfortunately, most web servers are misconfigured to still accept SSL 2.0, and TLS 1.1 and 1.2 have seen limited deployment. The practicality of the attack remains to be determined (for one, it isn't very fast — but if the intent is just to decrypt the data for later use, that isn't an impediment).

cancel ×

110 comments

yikes (1)

datapharmer (1099455) | more than 2 years ago | (#37459176)

gee golly I guess we better just turn it all off and call it quits before the hackers get us.

Re:yikes (0)

Anonymous Coward | more than 2 years ago | (#37465694)

Don't worry, it's on The Register so it'll almost certainly be wrong, or just extremely sensationalist. Probably nothing to worry about then.

Re:yikes (1)

hesaigo999ca (786966) | more than 2 years ago | (#37467092)

You do realize that 90% of websites out there still use only 2.0 as they are not 3.0 compliant?

Re:yikes (1)

hesaigo999ca (786966) | more than 2 years ago | (#37467112)

Who do you do your banking with, I want to see if they are still using 2.0, as I know 90% ofg websites are still on 2.0 as we speak

Javascript (3, Informative)

Hatta (162192) | more than 2 years ago | (#37459178)

From the looks of it, they use javascript on the target computer to capture some plain text which helps them break the keys. So as a temporary measure, disable javascript until browser makers catch up.

Re:Javascript (3, Informative)

MightyMartian (840721) | more than 2 years ago | (#37459190)

Yeah, and see how many websites built in the last eight or nine years work without Javascript... Hell, for real security, go back to using Gopher!

Re:Javascript (4, Insightful)

Hatta (162192) | more than 2 years ago | (#37459318)

For one, /. works a lot better with javascript disabled.

Re:Javascript (0)

Anonymous Coward | more than 2 years ago | (#37459506)

Thank you for your notice! After fucking /. screwed up completely without JS some months ago, I allowed an exception in Noscript, cursing them every time I came here to read (that is, several times a day). Now I just disabled the exception again. This is much better!

Re:Javascript (0)

Anonymous Coward | more than 2 years ago | (#37460460)

Pff, real geeks taste the bits with their tongue by licking the phone socket wires!

Re:Javascript (4, Funny)

MachDelta (704883) | more than 2 years ago | (#37460508)

No way man, this place is so much better with ja

Working...

v

Working...

ascr

Working...

ip

Working...

*Ctrl+W*

Working...

*Ctrl+WWWWWWWW*

Working...

*Alt+F4*

Re:Javascript (1)

tlhIngan (30335) | more than 2 years ago | (#37459428)

Yeah, and see how many websites built in the last eight or nine years work without Javascript... Hell, for real security, go back to using Gopher!

For quite a while, Apple's actually worked decently without javascript. Heck it even renders pretty much the same (it was only until I noticed things were a bit "off" that I realized NoScript was blocking it).

I think though the iTunes pages have completely broken now as have a few others. But until recently, they had a site that worked and acted pretty good without Javascript.

Re:Javascript (1)

triffid_98 (899609) | more than 2 years ago | (#37459484)

The really awful ones that embed full-screen flash apps instead of javascript?

Re:Javascript (1)

Calos (2281322) | more than 2 years ago | (#37460310)

Not even those, any more many sites use JS to check for Flash and the installed version :/

Re:Javascript (3, Insightful)

vlm (69642) | more than 2 years ago | (#37459496)

Yeah, and see how many websites built in the last eight or nine years work without Javascript... Hell, for real security, go back to using Gopher!

A good first order approximation is any website that is even vaguely attempting to be ADA compliant probably works fine without javascript.

Run with "noscript" for awhile, maybe a couple years, and you'll come to agree.

Re:Javascript (0)

Anonymous Coward | more than 2 years ago | (#37460130)

What do dentists have to do with websites?

ADA... (2)

KingAlanI (1270538) | more than 2 years ago | (#37461908)

Americans With Disabilities Act, not American Dental Association

Reminds me of a web-design instructor in highschool who was real big on trying to make one's sites disabled-accessible. For instance, make the site decipherable and navigable by screen readers for the blind

http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/ [w3.org]
http://www.w3.org/WAI/ [w3.org]

That it's related to backwards compatibility has to do with vlm's point AFAIK.

Re:Javascript (1)

EdIII (1114411) | more than 2 years ago | (#37462556)

Most people don't even know what ADA compliant even means. Furthermore, what the heck does a client-side language have to do with disabled people? How does javascript inherently prevent a disabled person from interacting with a website?

I don't have a single website that does not use javascript via JQuery. It just works.

NoScript? Fine. As a default that is. You will run into more sites that require javascript to do something, than ones that do not. We just redirect to a page that asks you to turn on javascript. If you don't trust enough to turn it on, but trust us enough to allow us to do recurring billing, than there is something wrong.

Unless you want a whole lot of forms and page refreshes, you need AJAX and the ability to rewrite the DOM client side for cleaner looking websites that don't require an entire page refresh, or a redirect to a working page, than a redirect back to the original page with the new data. Javascript simplifies things a lot more than Flash or Silverlight. That's for damn sure.

Of course, there is another article about TLS being broken. With javascript you can add your own layered encryption to the AJAX calls making it a little more secure. Cannot do that passing back data in forms.

Javascript is only an issue with websites that you don't trust. I find it invaluable for so many reasons as a developer and don't really care if you don't want to use it.

For landing pages and home pages we don't use any javascript at all, but is it really required on a home page?

I will ask again, how the heck does javascript inherently "violate" ADA compliance? Which for the record, is a bunch of BS for 90% of all websites. If you can't see, then some websites are just not for you. It would be too hard, and in some cases not even feasible, to translate the visual impact to auditory data. Additionally, javascript would actually be perfect client side to provide a data object that a braille reader could interpret. The client side applications to do so should not be the responsibility of the website owners and developers. All we should need to do is provide a standardized document format, or heavens no, have the ADA supported open source braille reader be able to interpret a DOM in real time and notify the person audibly that a change has occurred and how.

The deaf? Not all that much data on websites is auditory in the first place. Only real place to apply it would be lyrics to music, and then you would draw the wrath of the mentally challenged. Not any mentally challenged person the ADA would support either. I am speaking about all the execs and lawyers in Big Content.

Re:Javascript (0)

Anonymous Coward | more than 2 years ago | (#37464634)

So you're saying that your personal feelings as a developer are more important than the costumers preferences? Perhaps we don't trust you because you'll let any fly by night post malicious ads for penny shavings? With your recurrent billing we've got a line of recourse available in the form of our credit cards costumer service department, there aren't any internet hit squads we can have execute you for your dickheadedness yet, unfortunately.

Re:Javascript (1)

petteyg359 (1847514) | more than 2 years ago | (#37468742)

So do you provide a costume-making service, or do you service the costume-makers?

Re:Javascript (0)

Anonymous Coward | more than 2 years ago | (#37468730)

Try using a screen reader with a heavy JS page.

Re:Javascript (0)

Anonymous Coward | more than 2 years ago | (#37460098)

Agreed, ... Actually at that point you might as well just pack up your computer send it back to the factory you got it from and go live in the woods,.... come on disable javascript, what world do you live in...

Re:Javascript (1)

Yvanhoe (564877) | more than 2 years ago | (#37460446)

An ancient IT world in which security is more than a myth or an utopian goal. Trading security for convenience is doomed to wreck the web.

Re:Javascript (4, Insightful)

dissy (172727) | more than 2 years ago | (#37460462)

Yeah, and see how many websites built in the last eight or nine years work without Javascript... Hell, for real security, go back to using Gopher!

As a happy noscript user I was about to reply similarly to VLM below...

But instead it prompted me to check how many entries are in my noscript whitelist after using the same firefox profile for a bit over 3 years, and there are only 275 entries, of which 80 are various internal IPs for work related webapps and testing/development (Which I really need to clean out)

I don't think it's too bad of a sign that in 3 years only 200 websites I've visited were 'broken' without javascript! I was actually expecting a much higher number.

Even with that 200, or lets include the internal webapp sites at work and say 300, with the number of websites I've visited over the past three years it has to be in the high four digits. That is a pretty awesome ratio!

Most websites really do not break enough to matter when rolling without javascript. Even in mitigating this type of attack, I would rather white list the few sites that need it than leave javascript blanket open to every website out there.

Of course this solution isn't 100% perfect (It's "only" mostly perfect), so it will no doubt get poopoo'ed here on slashdot for not being over 100% perfect in every way

Re:Javascript (2)

grim4593 (947789) | more than 2 years ago | (#37461268)

Usually I just temporarily allow sites so they don't end up in my white list. Many sites are broken without JS.

Re:Javascript (1)

icebraining (1313345) | more than 2 years ago | (#37461344)

Don't you use the temporary permissions? I use them for most websites which I don't visit regularly, and AFAIK those don't appear in the whitelist.

Re:Javascript (1)

dissy (172727) | more than 2 years ago | (#37468044)

Don't you use the temporary permissions? I use them for most websites which I don't visit regularly, and AFAIK those don't appear in the whitelist.

You are correct that temp items are not added to the whitelist (At least not the one you can export)

I don't really use it though. Not in this way at least.

When I first decide I want to allow a function on a website, if there are multiple domains listed (Usually embedded video pages are the worst at this), I will use temporary allow/block to find the right domain to allow just what I am wanting.

Once I figure out which domains need allowed however, I go back and make them permanent. If I don't trust the website enough to add them to my whitelist, I generally don't want to run Any javascript from them even temporarily.

I suppose for most people however, temp entries would be much larger of a cumulative total.

Re:Javascript (1)

antdude (79039) | more than 2 years ago | (#37461392)

Doesn't Gopher have security vulnerabilities too? ;)

Re:Javascript (1)

lonecrow (931585) | more than 2 years ago | (#37464118)

Pretty much all of mine. Just saying...

Re:Javascript (1)

PJ6 (1151747) | more than 2 years ago | (#37464358)

Yeah, and see how many websites built in the last eight or nine years work without Javascript... Hell, for real security, go back to using Gopher!

Javascript will be long gone from mainstream by then.

Re:Javascript (1)

WuphonsReach (684551) | more than 2 years ago | (#37464428)

Yeah, and see how many websites built in the last eight or nine years work without Javascript... Hell, for real security, go back to using Gopher!

There are something on the order of a few million websites out there, maybe a few hundred million.

95% of the time, you're probably visiting the same small set of websites, so just whitelist those. The other 5%? Temporary whitelist when you visit them. If they're worth visiting again, then maybe you whitelist them next week.

Which is a big step up from letting every single website out there that you happen to browse to, or which gets served up via some asinine server include, or because a hacked page imports javascript from some evil hacker site, or because a malicious web ad gets served up run stuff on your machine in a way that will infect your profile.

It may not be perfectly safe (nothing is), but you'll end up infected 10x to 100x less by using whitelisting.

And I would say that at least 80-90% of the sites that I visit once-only work just fine without Javascript or Flash enabled. Those that don't? Well, their competitors are about 3 clicks away. (Or else they have to be extra compelling to make me feel like it's worth it to whitelist or even temporarily allow.)

Re:Javascript (1)

ge7 (2194648) | more than 2 years ago | (#37459214)

And how you think they will inject that javascript into the webpage, exactly? They cannot.

Re:Javascript (1)

Anonymous Coward | more than 2 years ago | (#37459286)

Okay then how do we get malware infections from reputable sites? Yeah the easy way is just to buy ads, the info you harvest would make it well worth the investemnt. And as always human stupidity is unpatchable, you would be surprised by how many people click on links sent to them still.

Re:Javascript (1)

sgrover (1167171) | more than 2 years ago | (#37459288)

me thinks you have spoken too soon. The right answer is "it depends". But, there are ways to get arbitrary javascript to run on web pages. cross site scripting, simple form submission of JS code, MiTM injection, malicious code on the server, etc.

OR, you know something I don't. If so, please share.

Re:Javascript (1)

Joce640k (829181) | more than 2 years ago | (#37459612)

Most of those won't work on an SSL connection. I think the only one that would is a compromised server, but if a (eg) Paypal server is compromised then you've got a lot bigger problems to worry about.

Re:Javascript (1)

Lennie (16154) | more than 2 years ago | (#37460744)

This is Man-in-the-Middle attack which injects the JavaScript code in the webpage in the SSL-stream I guess...?

Or do it on the HTTP-page...?

I guess we'll know in a few days.

Re:Javascript (1)

Joce640k (829181) | more than 2 years ago | (#37465538)

This is Man-in-the-Middle attack which injects the JavaScript code in the webpage in the SSL-stream.

SSL prevents that (it would be pretty useless otherwise...)

Re:Javascript (2)

framed (153355) | more than 2 years ago | (#37459718)

MiTM doesn't work against https unless the users are accepting bad certs already. If the page you're looking at was sent over https, its not alterable to include malicious javascript en-route. Someone on the network doesn't have your key, and so they can't spoof a request to take advantage of persistent https connections. XSS is dependent on your users looking at each others data and you not filtering it well. So unless your server or client are already owned (at which point this doesn't matter), or your users are randomly accepting bad certs (at which point it still doesn't matter), the only vector is a pre-existing unpatched XSS vulnerability on one of the servers https pages. (right?)

Re:Javascript (1)

Qzukk (229616) | more than 2 years ago | (#37461048)

If the question is simply a matter of figuring out the plaintext, why bother with javascript at all? After all, somewhere in the middle of this page is going to be the plaintext "If the question is a matter of figuring out the plaintext, why bother with javascript at all?"

Re:Javascript (5, Informative)

chrb (1083577) | more than 2 years ago | (#37459338)

They can. Not only is Javascript injection possible, it has already been done by at least one malicious government [theregister.co.uk] : "Malicious code injected into Tunisian versions of Facebook, Gmail, and Yahoo! stole login credentials of users critical of the North African nation's authoritarian government, according to security experts and news reports."

Re:Javascript (0)

Anonymous Coward | more than 2 years ago | (#37459434)

how about by a 3rd party without special access to the infrastructure...

Re:Javascript (1)

Joce640k (829181) | more than 2 years ago | (#37459560)

Javascript injection into an SSL connection is a bit more difficult...

Re:Javascript (3, Insightful)

increment1 (1722312) | more than 2 years ago | (#37460020)

I think the idea is to inject the Javascript before the connection goes SSL. So maybe something like:

1. You go visit www.gmail.com
2. They intercept and return an http version of the page to you with the javascript injected
3. The Javascript opens up an https connection with gmail.com, establishing the IV over a persistent connection.
4. The Javascript redirects to the https page, so you don't notice the lack of https.
5. You log in to the https page as normal, using the browsers already established https connection which they can apparently decrypt.

If not for step 4, this attack would be little different than just intercepting and returning a non-https page and hoping that you didn't notice the difference. Depending on how long your browser keeps a persistent https connection open, I wonder if it is possible to have the javascript on an independent page, making the https requests to the target site to establish the connection before you even go to the target site.

Re:Javascript (1)

Joce640k (829181) | more than 2 years ago | (#37465528)

Unless I'm very mistaken, SSL doesn't work like that. SSL is designed to prevent man-in-the-middle attacks. The session key for the encryption has to be signed using Google's public key - which the attacker can't do.

(Or maybe they can, after all the recent hacks...)

Re:Javascript (1)

increment1 (1722312) | more than 2 years ago | (#37469890)

Unless I'm very mistaken, SSL doesn't work like that. SSL is designed to prevent man-in-the-middle attacks. The session key for the encryption has to be signed using Google's public key - which the attacker can't do.

The SSL session is signed, but according to this new attack, if an attacker can inject known plaintext and see the sniffed encrypted text of the same, then they can somehow manage to decrypt some portion (or all) further communication. So it is not breaking the establishment of the SSL connection (as a normal MITM attack would), it is directly decrypting the encrypted communication (the confidentiality component of SSL).

Re:Javascript (1)

Gyorg_Lavode (520114) | more than 2 years ago | (#37470706)

I'd be curious if the injected traffic has to be on the targetted site... I wonder if the approach is to inject the javascript on some non-encrypted page and use it to load the encrypted known text.

Re:Javascript (1)

mzs (595629) | more than 2 years ago | (#37479480)

That makes much more sense, I would expect to see the 'some of the data is not encrypted warning' with what increment1 proposed.

Re:Javascript (2)

Reece400 (584378) | more than 2 years ago | (#37459950)

A lot of banks use services such as Advanced web analytics, which include bits of javascript from advanced-web-analytics.com inside their secure pages. I'm not sure how secure their servers are, but I for one have blocked their server on our proxy.

Re:Javascript (0)

Anonymous Coward | more than 2 years ago | (#37460492)

They don't have to inject Javascript into that webpage. I.e., the script doesn't have to run in the origin of the secure site. They only need a script to generate send certain chosen requests to the site.

Re:Javascript (1)

Baloroth (2370816) | more than 2 years ago | (#37459356)

Come on, be logical. The only adequate response to a not-yet-presented attack vector that requires a packet sniffer on the network and injected Javascript in the webpage while taking hours to decrypt a single cookie is to stop using the Internet altogether until it gets fixed. Based on Slashdot user comments, it's the only reasonable thing to do.

Re:Javascript (0)

Anonymous Coward | more than 2 years ago | (#37463196)

That might not always work if there's another potential like besides JS. Disconnecting ethernet should work until there's a better solution.

Should we disable TLS 1.0 in browsers? (1)

Anonymous Coward | more than 2 years ago | (#37459246)

What would be the ramifications of disabling TLS 1.0 in the browser (Opera)? By default, TLS 1.0 is enabled and TLS 1.1 & 1.2 is disabled. Also, SSL 3 is enabled and there is no option for earlier versions, so I assume SSL 2 is already disabled in Opera.

Re:Should we disable TLS 1.0 in browsers? (3, Informative)

chrb (1083577) | more than 2 years ago | (#37459314)

The ramification is that you won't be able to use HTTPS on the vast majority of web sites. According to the Register [regmedia.co.uk] , of 1 million web servers sampled: 604,242 supported TLS v1.0, 838 supported TLS v1.1, and 11 supported TLS v1.2.

Re:Should we disable TLS 1.0 in browsers? (1)

Mister Whirly (964219) | more than 2 years ago | (#37460332)

Maybe those numbers will change after this exploit becomes more known.

Re:Should we disable TLS 1.0 in browsers? (3, Informative)

Necroman (61604) | more than 2 years ago | (#37459328)

Stolen from the thread on this on reddit [reddit.com] :

That's actually exactly how it's supposed to work. See Appendix E of the TLS 1.2 RFC. The client sends its highest-supported version in its first message, and the server replies with the highest-supported version that is less than or equal to the version the client sent.

Unfortunately, some older (mostly third-party) servers break entirely if they receive something that they don't recognize. As such, TLS 1.1/1.2 is often disabled by default for compatibility reasons, even if it is supported.

NSS (Mozilla/Firefox) and OpenSSL (used in Apache's mod_ssl) also only support up to TLS 1.0 in their stable versions, as there hasn't really been a compelling reason for them to add TLS 1.1/1.2 support until now.

Re:Should we disable TLS 1.0 in browsers? (0)

Anonymous Coward | more than 2 years ago | (#37460564)

If you're using Windows XP, TLS 1.0 is disabled by default.
[ It never hurts to verify: Control Panel, Internet Options, Advanced tab, Security section. The checkbox for Use TLS 1.0 should be empty. ]

Re:Should we disable TLS 1.0 in browsers? (1)

Ant P. (974313) | more than 2 years ago | (#37459972)

SSL2 has been gone in any decent browser for a long time now. The latest versions of Chrome (currently 15.0.874.1) don't even have checkboxes for SSL3/TLS any more, so fuck knows what data it's leaking behind my back...

Re:Should we disable TLS 1.0 in browsers? (2)

Calos (2281322) | more than 2 years ago | (#37460378)

Sure they do: Options -> Under the Hood. There's a checkbox for SSL 3.0, and one for TLS 1.0. So, similar to what the poster above you said, it looks like they don't expose TLS 1.1/1.2 in releases yet.

Not very fast? (5, Interesting)

chrb (1083577) | more than 2 years ago | (#37459264)

The attack can apparently be completed in about 5 minutes. That is plenty of time for attacking the average online banking session, never mind gmail and other sites that people log in to for hours at a time.

The attack appears to use javascript to push known plaintext over HTTPS to the web site before the actual login request is sent, so that the login credentials are transferred as part of a persistent SSL connection which now has a known IV. If this is correct, then the attack could be avoided by disabling persistent HTTPS connections in the browser. There is a performance cost to this, but I think most people would prefer to feel secure, and wouldn't really notice the extra costs of opening and closing individual HTTPS sessions for each browser request. Proxies might break that though.

Re:Not very fast? (0)

Anonymous Coward | more than 2 years ago | (#37459500)

They said every fix they suggested breaks something that people use. I'm guessing your fix is among those.

Re:Not very fast? (1)

atisss (1661313) | more than 2 years ago | (#37459784)

Banks (at least on this corner of earth) do use secondary authentication for transactions - that's physical code calculator/sheet, so even having bank's SSL session won't help in transfering funds.

Re:Not very fast? (0)

Anonymous Coward | more than 2 years ago | (#37460006)

Online bill pay?

Also, from an account you can learn routing number and account number and plenty of details to forge a bank transaction.

Re:Not very fast? (1)

am 2k (217885) | more than 2 years ago | (#37460392)

At least with my bank, I can sign multiple transactions with a single OTP. If you can intercept the connection, you can insert another transfer into the list and then alter the HTML to not display that entry, but I'd still sign it along with the others I actually want to do.

Re:Not very fast? (1)

owlstead (636356) | more than 2 years ago | (#37463226)

With a high enough amount, my bank will also require to input the total sum in the calculator. A long time ago they did not say what the number meant (which is weird, because people will enter it without checking) but now it has been made explicit.

Speculation on the attack (2)

dachshund (300733) | more than 2 years ago | (#37463232)

Here's my description/speculation about how it works. Apologies for the blog whoring, I can't type it all up again:

http://practicalcrypto.blogspot.com/2011/09/brief-diversion-beast-attack-on-tlsssl.html [blogspot.com]

Re:Speculation on the attack (0)

Anonymous Coward | more than 2 years ago | (#37463728)

Here's my description/speculation about how it works. Apologies for the blog whoring, I can't type it all up again:

I assume your keyboard has Ctrl keys?

Re:Speculation on the attack (1)

Myopic (18616) | more than 2 years ago | (#37463870)

I don't at all mind the blog whoring, but copy-paste is pretty easy.

Re:Speculation on the attack (1)

dachshund (300733) | more than 2 years ago | (#37465776)

XOR symbols, images and boldface text don't copy paste very nicely.

3 ways to be safe(r) from this attack... apk (0)

Anonymous Coward | more than 2 years ago | (#37470246)

Because TLS1.1 & below ARE vulnerable to this - here is how you do that:

---

1.) Opera (has TLS 1.2 but NOT BY DEFAULT - you MUST set it, thus - Disable javascript globally (as you CAN in Opera) & then site "by site preferences" in Opera (only browser I know that does it) &, then, to allow javascript on sites that do SSL or not? Do this (in combination w/ using TLS 1.2, & it's NOT THE DEFAULT, you HAVE TO SET IT in Opera's Tools menu, Preferences submenu, Advanced tree item, Security tree subitem section)

2.) IE9 (Has better encryption for SSL than TLS1.1 & below)

3.) Disable javascript

---

* In fact, so you know I am "legit here"? You MAY wish to read up on this:

---

Hackers break SSL encryption used by millions of sites (Beware of BEAST decrypting secret PayPal cookies)

By Dan Goodin in San Francisco - Posted in ID, 19th September 2011 21:10 GMT

http://www.theregister.co.uk/2011/09/19/beast_exploits_paypal_ssl/page2.html [theregister.co.uk]

---

"Here endeth the lesson..."

APK

P.S.=> I suppose until Mozilla implements it, NoScript MAY help also, but I wouldn't trust SSL based sites then, until they update FireFox to have TLS version 1.2 (or better when that comes out IF it comes out etc./et al)... apk

Ah ha! (4, Funny)

Howard Beale (92386) | more than 2 years ago | (#37459294)

Now we know what that 30,000 node EC2 cluster was for...

Re:Ah ha! (1)

modf (213273) | more than 2 years ago | (#37459986)

Thanks, that is the first time ./ has made me laugh in a while.

Webserver deployment flexibility (2)

archen (447353) | more than 2 years ago | (#37459304)

unfortunately most web servers are misconfigured to still accept SSL 2.0, and TLS 1.1 and 1.2 have seen limited deployment.

Uh, I'm pretty sure the web server is required to have enough flexibility for people to view the content. If the user demands security, that should to be negotiated by the client trying to use the most secure option possible. Saying a server is "misconfigured" might be nice for someone living in a bubble where everything is up to date and users have a clue, but in the real world servers don't have this option.

Re:Webserver deployment flexibility (1)

ravenspear (756059) | more than 2 years ago | (#37460556)

SSLv2 being accepted by the server is a misconfiguration.

I manage multiple sites used by Fortune 100 companies (who are often slow to upgrade clients) and have had SSLv2 turned off on the server for years.

Re:Webserver deployment flexibility (3, Insightful)

izomiac (815208) | more than 2 years ago | (#37461206)

Fall back to regular HTTP then. There's no point in insecure HTTPS. Security is the "S" in these protocols and the sole reason for their existence. Someone who opts to use them has explicitly requested security, not compatibility, as most sites lack any form of SSL.

For most bugs, you're right. Convenience trumps most other things in software. Security is not one of them. Your users are trusting you to keep them safe. An insecure browsing session will eventually (quickly?) lead to money being stolen or civil rights activists being killed, that's why anyone puts up with the inconvenience of security in the first place.

Re:Webserver deployment flexibility (1)

muckracer (1204794) | more than 2 years ago | (#37477530)

> Fall back to regular HTTP then. There's no point in insecure HTTPS.

But there is a point in insecure HTTP??

> Security is the "S" in these protocols and the sole reason for their
> existence.

I know this is hard for guys like you to accept, but the much-touted "S" has become a ridiculous notion. Especially when coupled with some outlandish DEV-belief, that users "have a sense of security", trained or otherwise.
SSL IN ITS CURRENT FORM IS BROKEN AND HAS BEEN SINCE THE BEGINNING!!

Thank You for this Article.... (0)

Anonymous Coward | more than 2 years ago | (#37459378)

Now my browser is correctly configured.

wait what (1)

Hazel Bergeron (2015538) | more than 2 years ago | (#37459390)

Surely Javascript sent from the server with which the SSL session has been made has the opportunity to read what's being transmitted to/from the server anyway? And third party Javascript doesn't get access to random SSL connections with other domains?

What are these guys claiming? That known plaintext at the start of an SSL session plus access to all packets passing between client and server means further characters can eventually be worked out?

Re:wait what (1)

dave562 (969951) | more than 2 years ago | (#37459830)

What are these guys claiming? That known plaintext at the start of an SSL session plus access to all packets passing between client and server means further characters can eventually be worked out?

That seems to be what they are claiming. If you know at least SOME of what is encrypted, it becomes much easier to decrypt the rest.

Re:wait what (0)

Anonymous Coward | more than 2 years ago | (#37463198)

Seems like they are doing this http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.61.5887. The attack they describe in the second article seems exactly taken from that paper circa 4 years ago, I don't know what if anything is new. Is it me or is there almost no information in the articles linked to by Slashdot?

OpenVPN, Tor, others (0)

Anonymous Coward | more than 2 years ago | (#37459472)

Does this mean OpenVPN, Tor, IMAP/POP3-over-SSL clients and other programs that are using SSL/TLS are vulnerable too ? Or is it just web browsers ?

Note, I haven't RTFA.

Re:OpenVPN, Tor, others (3, Insightful)

GameboyRMH (1153867) | more than 2 years ago | (#37459754)

Not really. This attack makes the encryption easier to brute-force later on by first passing known data over it. It's like if an attacker could force a known file onto your encrypted disk and know its exact location on the disk, that would then make it easier to brute-force the key.

So yeah it shows that there are some weaknesses in the algorithm, but if another party can inject known data into your SSH/Tor/OpenVPN session you have much bigger problems anyway.

Re:OpenVPN, Tor, others (0)

Anonymous Coward | more than 2 years ago | (#37460948)

Unless you're flat out convinced that Carnivore is a myth (it is not):

1) Publish .onion site --> Known data
2) Watch network connections via backbone junctions --> PatrioTerror Act
3) Unwrap 5-6 layers of tunneling given known data from the outside in --> This attack
4) ???
5) Prison! --> FBI

I'm proud to be un American

Re:OpenVPN, Tor, others (0)

Anonymous Coward | more than 2 years ago | (#37464122)

Otherwise known as "B&, V&, and C&".

Re:OpenVPN, Tor, others (1)

GameboyRMH (1153867) | more than 2 years ago | (#37465892)

From what I understand this attack requires known data to be sent through from the public key (client) side, so that attack is pretty useless - if an attacker can force known data through your Tor connection from your side he's either broken into your computer or the .onion site (to plant the malicious JS on it).

Isn't SSL 3.0 affected as well? (1)

OverTheGeicoE (1743174) | more than 2 years ago | (#37459492)

It looks like the summary above is mistaken. TFA says that TLS 1.0 and before are affected. Shouldn't that include SSL 3.0 as well as 2.0? It matters because if the summary is correct, we can tell our browsers not to use TLS 1.0 but keep using SSL 3.0. If not, we're stuck waiting for fixes from, well, everybody.

Re:Isn't SSL 3.0 affected as well? (2)

yuhong (1378501) | more than 2 years ago | (#37459618)

Yea, to the Slashdot editors:
 

Note that this only affects SSL 3.0 and TLS 1.0

Re:Isn't SSL 3.0 affected as well? (1)

blair1q (305137) | more than 2 years ago | (#37459992)

Nice. Guess which are the only two options available on this browser...

Re:Isn't SSL 3.0 affected as well? (1)

yuhong (1378501) | more than 2 years ago | (#37464564)

Yea, SSL 2.0 has worse flaws, not only the protocol flaws but also that Netscape 1.x's random number generator was not really random too.

Re:Isn't SSL 3.0 affected as well? (1)

demonbug (309515) | more than 2 years ago | (#37460132)

Yea, to the Slashdot editors:

 

Note that this only affects SSL 3.0 and TLS 1.0

The editors are too busy telling us that this is the first article from the submitter to be accepted; you can't expect them to perform that important function and actually glance at the article, now can you?

Yes, SSL 3.0 and TLS 1.0 are both affected. (1)

ftexperts (2042636) | more than 2 years ago | (#37459806)

Yes, SSL 3.0 and TLS 1.0 are both affected. And yes, we'll be waiting on fixed from just about everyone. (Or, everyone may just move to TLS v1.1 - that's safe too.)

Here's a page that's tracking this for file transfer applications that includes a nice discussion of general purpose web servers and browsers and their current "support of TLS v1.1" status at the end: http://www.filetransferconsulting.com/file-transferbeast-tls-vulnerability/ [filetransf...ulting.com]

SSL v3 (1)

drolli (522659) | more than 2 years ago | (#37459518)

So does it now affect sslv3 even with TLS1.0 activated? If not, then upgrade firefox. Version 6.0.2 has ssl2 disabled.

Re:SSL v3 (1)

GNious (953874) | more than 2 years ago | (#37465184)

While reading this, I received notification from Firefox that an update was available. Was thinking "That was quick!", but alas - is a fix for reducing memory footprint.

In Soviet Russia... (1)

Roachie (2180772) | more than 2 years ago | (#37459948)

The Browser break hackers!

Apache2 fix (1)

tayhimself (791184) | more than 2 years ago | (#37460324)

In my view, this should fix the error provided you change TLSv1 to 1.1 or 1.2. We are forced to run SSLv3 on our servers for PCI compliance.

SSLProtocol -all +SSLv3 +TLSv1
SSLCipherSuite ALL:!aNULL:!ADH:!eNULL:!LOW:!EXP:RC4+RSA:+HIGH:+MEDIUM#SSLv3:+HIGH:+MEDIUM

Re:Apache2 fix (0)

Anonymous Coward | more than 2 years ago | (#37461064)

This is the worst piece of advice I have ever seen.
Either you are trolling or... how did you not realize that the example does the exact opposite of what one would want, by disabling everything except for the flawed protocols?

Re:Apache2 fix (0)

Anonymous Coward | more than 2 years ago | (#37461686)

A) your command is wrong
B) your command cannot ever be right unless you've got the rare shiny apache built against GNUtls, because openssl does not support 1.1 or 1.2.

If they won't disclose, I will (1)

Anonymous Coward | more than 2 years ago | (#37461486)

This attack uses Javascript (previously-injected) to try to perform an adaptive chosen-plaintext attack (explicit mention of which dates from 2002[1]). TLS 1.1 and up use explicit random IVs for each CBC block to mitigate that attack, but TLS 1.0 and the older SSL protocols use the previous trailing ciphertext block as the IV for the next packet.

I question whether it really brings anything new to the table as Javascript injection brings the ability to do much more devious things rather than messing around with encryption trying to determine a single session key, but I thoroughly encourage everyone to be running TLS v1.2 already anyway. There's no excuse for having it switched off - all older, incompatible implementations should have been phased out already as they probably don't have fixes for the renegotiation vulnerability anyway.

[1] http://www.openssl.org/~bodo/tls-cbc.txt

Did anyone read the story? (1)

Anonymous Coward | more than 2 years ago | (#37462194)

It says "against a victim who is on a network on which they have a man-in-the-middle position" so they have installed monitoring software on the victims computer that gives them full access in which case why would they need this is the first place?

Re:Did anyone read the story? (2)

neonsignal (890658) | more than 2 years ago | (#37464200)

It's "man-in-the-middle" because it requires a javascript injection. That might be possible through vulnerabilities in particular websites (eg embedded ads with javascript, or a crafted link, etc). It could also be injected by an ISP.

Already fixed in OpenSSL in TLS 1.0? (1)

Anonymous Coward | more than 2 years ago | (#37465228)

According to this post, OpenSSL using TLS 1.0 should not be susceptible:

http://marc.info/?l=openssl-dev&m=131654410924995&w=2

Don't know about NSS though.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...