Hackers Break Browser SSL/TLS Encryption

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).

Comments

yikes

[datapharmer]

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

Re:yikes

[Anonymous Coward]

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

[hesaigo999ca]

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

Re:yikes

[hesaigo999ca]

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

[Hatta]

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

[MightyMartian]

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

[ge7]

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

Re:Javascript

[Anonymous Coward]

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

[sgrover]

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

[Hatta]

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

Re:Javascript

[chrb]

They can. Not only is Javascript injection possible, it has already been done by at least one malicious government: "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

[Baloroth]

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

[tlhIngan]

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

[Anonymous Coward]

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

Re:Javascript

[triffid_98]

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

Re:Javascript

[vlm]

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

[Anonymous Coward]

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

[Joce640k]

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

Re:Javascript

[Joce640k]

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

[framed]

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

[Reece400]

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

[increment1]

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

[Anonymous Coward]

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

[Anonymous Coward]

What do dentists have to do with websites?

Re:Javascript

[Calos]

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

Re:Javascript

[Yvanhoe]

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

[Anonymous Coward]

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

Re:Javascript

[dissy]

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

[Anonymous Coward]

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

[MachDelta]

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

[Lennie]

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

[Qzukk]

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

[grim4593]

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

Re:Javascript

[icebraining]

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

[antdude]

Doesn't Gopher have security vulnerabilities too? ;)

Re:Javascript

[EdIII]

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

[Anonymous Coward]

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

Re:Javascript

[lonecrow]

Pretty much all of mine. Just saying...

Re:Javascript

[PJ6]

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

[WuphonsReach]

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

[Anonymous Coward]

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

[Joce640k]

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

[Joce640k]

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

[dissy]

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

[Anonymous Coward]

Try using a screen reader with a heavy JS page.

Re:Javascript

[petteyg359]

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

Re:Javascript

[increment1]

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

[Gyorg_Lavode]

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

[mzs]

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

[Anonymous Coward]

so would using HttpsEverywhere help to protect you?

Should we disable TLS 1.0 in browsers?

[Anonymous Coward]

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?

[chrb]

The ramification is that you won't be able to use HTTPS on the vast majority of web sites. According to the Register, 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?

[Necroman]

Stolen from the thread on this on reddit:

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?

[Ant P.]

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?

[Mister Whirly]

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

Re:Should we disable TLS 1.0 in browsers?

[Calos]

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.

Re:Should we disable TLS 1.0 in browsers?

[Anonymous Coward]

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?

[Ant P.]

I'll repeat myself: in 15.0.874 those boxes are gone.

Not very fast?

[chrb]

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?

[Anonymous Coward]

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

Re:Not very fast?

[atisss]

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?

[Anonymous Coward]

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?

[am 2k]

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?

[owlstead]

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.

Ah ha!

[Howard Beale]

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

Re:Ah ha!

[modf]

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

Webserver deployment flexibility

[archen]

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

[ravenspear]

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

[izomiac]

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

[muckracer]

> 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....

[Anonymous Coward]

Now my browser is correctly configured.

wait what

[Hazel Bergeron]

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

[dave562]

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

[Anonymous Coward]

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

[Anonymous Coward]

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

[GameboyRMH]

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

[Anonymous Coward]

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

[Anonymous Coward]

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

Re:OpenVPN, Tor, others

[GameboyRMH]

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?

[OverTheGeicoE]

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?

[yuhong]

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?

[blair1q]

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

Re:Isn't SSL 3.0 affected as well?

[demonbug]

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?

Re:Isn't SSL 3.0 affected as well?

[yuhong]

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.

SSL v3

[drolli]

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

[GNious]

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.

Yes, SSL 3.0 and TLS 1.0 are both affected.

[ftexperts]

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/

In Soviet Russia...

[Roachie]

The Browser break hackers!

Apache2 fix

[tayhimself]

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

[Anonymous Coward]

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

[Anonymous Coward]

http://images.memegenerator.net/instances/400x/9220715.jpg

Re:Apache2 fix

[Anonymous Coward]

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

[Anonymous Coward]

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

ADA...

[KingAlanI]

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/
http://www.w3.org/WAI/

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

Did anyone read the story?

[Anonymous Coward]

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?

[neonsignal]

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.

Speculation on the attack

[dachshund]

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

Re:Speculation on the attack

[Anonymous Coward]

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

[Myopic]

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

Re:Speculation on the attack

[dachshund]

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

Re:Speculation on the attack

[nullchar]

That post should be TFA this thread is discussing! Thanks for sharing.

Already fixed in OpenSSL in TLS 1.0?

[Anonymous Coward]

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.

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

[Anonymous Coward]

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

---

"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

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

[Anonymous Coward]

That won't work. The way TLS works is the client says 'hey I have 1.2" and the vast majority of servers reply, "cool, but I only do 1.0 so do that instead" and the client obliges. Old servers reply with "error there is nothing other than 1.0" so that's why the default is 1.0 on clients. Also everybody APK is a troll, I did not want to feed him, but felt it was important to let others know not to follow his 'legit' advice.

Time to blow you away AGAIN, AC troll... apk

[Anonymous Coward]

1.) So you use NETCRAFT's "What's that site running" here:

  http://uptime.netcraft.com/up/graph?site=slashdot.org

To determine what webserver a site runs (what build level), first.

2.) Then, query a search engine for what webservers have TLS 1.2 in them, ala:

http://www.google.com/search?sclient=psy-ab&hl=en&site=&source=hp&q=%22Apache%22+and+%22TLS+1.2%22&btnG=Search

3.) & if NEED be, write the website on what "mod_ssl" level they use currently & warn them to update to the one that has TLS 1.2...

* Easy as pie, & even EASIER than step #3, is to just use this:

https://www.ssllabs.com/ssldb/analyze.html?d=slashdot.org&s=216.34.181.45

That last tool I have to thank someone named "Lennie" here on in an exchange he & I had today (much more direct on determining SSL TLS level used on a site than my "detective methods")...

APK

P.S.=> Funniest part is, I'll never EVER get hit by "BEAST", because I don't use javascript here "indiscriminately" (hell, I never do, I don't even do "ecommerce" because I know the security-downsides of Javascript is why)... but, time to "take you apart" in your quotes now (the FUN part):

"That won't work. The way TLS works is the client says 'hey I have 1.2" and the vast majority of servers reply, "cool, but I only do 1.0 so do that instead" and the client obliges." - by Anonymous Coward on Thursday September 22, @10:25AM (#37479622)

See the above, & "tell us another one", ok? IF you don't have javascript active (especially "everywhere + indiscriminately" though? Like myself, you CANNOT BE HIT BY IT, period!).

Care to debate that, you ac troll??

---

"Old servers reply with "error there is nothing other than 1.0" so that's why the default is 1.0 on clients" - by Anonymous Coward on Thursday September 22, @10:25AM (#37479622)

So, see the above - I provide tools to check "server-side" also for TLS/SSL levels, what builds of a webserver have it, as well as what a server runs... simple!

(Guess you didn't KNOW that, eh, troll? LOL...)

First of all, I am ONLY extolling the fact that Opera already has a few "built in/native" mechanisms for combatting this (perhaps the best is its "by site" prefs & not using potentially dangerous things like iframes, plugins, javascript, cookies etc./et al, rather than its TLS 1.2 option it already has).

---

"Also everybody APK is a troll" - by Anonymous Coward on Thursday September 22, @10:25AM (#37479622)

Ahem: EXCUSE ME, but aren't YOU THE ONE TROLLING VIA AC REPLIES + ADHOMINEM ILLOGICAL LIBELLING ATTACKS NOW?

Yes, you are... pot calling the kettle black!

---

"I did not want to feed him, but felt it was important to let others know not to follow his 'legit' advice." - by Anonymous Coward on Thursday September 22, @10:25AM (#37479622)

What's not "legit" about what I wrote last round in Opera being able to defend a user, BROWSER SIDE (the topic here mainly) vs. SSL type attacks like "BEAST"?

(Now, I know this AC troll will run from this, or go off topic & attempt more illogical adhominem attacks, but I always have fun with him, making him look more ignorant than he already is, everytime)...

... apk

Re:Time to blow you away AGAIN, AC troll... apk

[Anonymous Coward]

Hi me again,

Here's what that link you provided says:

TLS 1.2 No
TLS 1.1 No
TLS 1.0 Yes

Like I said before, you can enable 1.2 in your client, but the client and server will still negotiate 1.0 (or get an error from some old broken web servers) the vast majority of the time. Sure you can disable javascript, but I took your original comment as do 1, 2, or 3. I wanted to let people know that doing 1 like you suggested was just a false sense of security.

Re:Time to blow you away AGAIN, AC troll... apk

[Anonymous Coward]

U got knocked out by apk on javascript http://it.slashdot.org/comments.pl?sid=2437396&cid=37483798 and slashdot.org has no SSL needed dumbass so you trying to take apk down on that is stupid. I don't use SSL on this site period and neither do others I'd say.

Again, so what: I don't use javascript... apk

[Anonymous Coward]

How does this attack "get to you"? Javascript! What don't I use again?? Javascript & I've advised THAT for years no less here -> http://www.google.com/search?sclient=psy-ab&hl=en&site=&source=hp&q=%22HOW+TO+SECURE+Windows+2000%2FXP%22&btnG=Search & far longer than that (since 1997, & for security purposes).

Plus, the subject here's about this attack & the fact is, that Opera has TLS 1.2 for SSL which IS IMMUNE to it, & 1.0 is not, period... see here:

Opera implements them ALL, period!

LMAO - between my "left hand jab" with TLS 1.2 in Opera which you got so 'wrapped up in'? My RIGHT HAND KNOCKOUT PUNCH OF JAVASCRIPT LIMITING (as I have for decades) KNOCKED YOU OUT, yet again, as you continually troll me via AC replies there, "hero" (gosh why do you do that? You aren't very confident in your own words is why)!

This? Ah, I just GOTTA say it, as-is-per-my-usual style:

This was just "too, Too, TOO EASY - just '2EZ'"

APK

P.S.=> U FAIL, period, overlooking I AM IMMUNE TO THIS BECAUSE I DON'T USE JAVASCRIPT & RECOMMENDED THE SAME TO OTHERS VS. THIS HERE, AND FOR YEARS NOW... U FAIL, as usual vs. myself U trolling ac coward... give up already - you amuse me to NO end & continually make ME LOOK GOOD in doing so!

... apk

My technique (no javascript) works AND

[Anonymous Coward]

See subject-line, plus OPERA HAS A SECURITY-CHECK GUI!

Opera's View menu -> Developer Tools submenu -> Page Security Info submenu (outlines what type of SSL, TLS, certificates & such that a site offers, by PAGE no less).

" Sure you can disable javascript, but I took your original comment as do 1, 2, or 3. I wanted to let people know that doing 1 like you suggested was just a false sense of security" -

Between my suggesting others disable javascript (until they check a site via this or the other pages & methods I suggested for testing TLS/SSL levels on webservers) & this built in Opera toolset for that type of test of SSL/TLS?

* Opera 11.51 again "FTW"...

APK

P.S.=> Ah yes - there is NOTHING QUITE LIKE FLOORING A "NAYSAYER AC TROLL", & you KNOW I've just GOTTA SAY IT, as-is-per-my-usual vs. AC trolls like yourself: This? This was just "too, Too, TOO EASY - just '2EZ'"...

... apk

SSH Tunneling

[dendrope]

If you have a computer at home running on a secured network, then SSH tunneling traffic while you're elsewhere should avert the problem.