Google Prepares Fix To Stop SSL/TLS Attacks

OverTheGeicoE writes "It was reported Tuesday that researchers had found a way to break the most commonly used SSL/TLS encryption in browsers. According to the Register, Google is pushing out a patch to fix the problem. The patch doesn't involve adding support for TLS 1.1 or 1.2. FTFA: 'The change introduced into Chrome would counteract these attacks by splitting a message into fragments to reduce the attacker's control over the plaintext about to be encrypted. By adding unexpected randomness to the process, the new behavior in Chrome is intended to throw BEAST off the scent of the decryption process by feeding it confusing information.' The fix is supposedly in the latest developer version of Chrome."

Comments

TLS 1.1 or 1.2?

[neokushan]

Call me ignorant here, but how hard would it be for people to enable TLS 1.1 or 1.2 support in browsers and sites, since that apparently isn't vulnerable?

Re:TLS 1.1 or 1.2?

[wisesifu]

Its not the only the browsers that need to support the newer versions of these protocols, but also the servers.

Re:TLS 1.1 or 1.2?

[Anonymous Coward]

Not much harder than it would have been for them to upgrade from IE 6, but difficulty doesn't appear to be the sole factor.

Re:TLS 1.1 or 1.2?

[woodsbury]

Wikipedia tells me TLS 1.1 came out in 2006 and 1.2 came out in 2008, yet still there are many sites that don't support them. It doesn't matter if your browser supports it if the people running the servers it's communicating with are too lazy to update, even after 5 years.

Re:TLS 1.1 or 1.2?

[Anonymous Coward]

Call me ignorant here, but how hard would it be for people to enable TLS 1.1 or 1.2 support in browsers and sites, since that apparently isn't vulnerable?

Surprisingly hard, because there is still around 1-2% of HTTPS servers that are not compliant with the TLS protocol specification and reset the connection when a client attempts to negotiate a version higher than they can understand. Usually in these cases TLS 1.1 means too high, client developers are mainly just waiting for the broken servers to disappear or get upgraded before they can turn on the switch and start using new TLS versions. TLS 1.2 is also a bit different from TLS 1.1, and TLS 1.0 for that matter, and requires a lot more testing, so it is not likely to become mainstream any time soon. However TLS 1.1 is a very minor upgrade and should be extremely easy to roll out for everyone interested.

Re:TLS 1.1 or 1.2?

[jonwil]

There are many many servers that will totally fail if the client claims to support TLS 1.1 or 1.2.

Re:TLS 1.1 or 1.2?

[Midnight Thunder]

Could clients detect this somehow and fall back to support the broken behaviour? For example on detection of an unexpected reset.

Re:TLS 1.1 or 1.2?

[Phaeilo]

Sure, but then what's the point of the fix?

Re:TLS 1.1 or 1.2?

[Chrisq]

Call me ignorant here, but how hard would it be for people to enable TLS 1.1 or 1.2 support in browsers and sites, since that apparently isn't vulnerable?

I think it would be hard for them to do this quickly. The Google Chrome solution is really a stopgap until then.

Re:TLS 1.1 or 1.2?

[chris.alex.thomas]

well, since it's such a small percentage, why not turn it on, let those sites fail, then when the owners of those sites complain, tell them to upgrade their shite servers and whilst their at it to get with the effing program. 1-2% of the servers in the world is enough to hold the world to ransom technologically is a stupidly simple problem to solve. why should we all suffer because of a few holdouts? cut the cord already!

Re:TLS 1.1 or 1.2?

[TheRaven64]

More importantly, deploy it in browsers, don't display the padlock, and do print a warning when using TLS 1.0. I'm sure sites will get upgraded nice and quickly once their customers start telephoning and saying 'my browser gave a scary warning when I tried to enter my credit card details!'

Re:TLS 1.1 or 1.2?

[Anonymous Coward]

Client developers are also waiting for API support. For example, Microsoft added TLS 1.1 and 1.2 support to Windows 7, but has shown no intentions to bring those to XP or Vista. Maybe you could get around that using a third-party library or something, but then you cannot use the standard APIs. Many developers will decide it isn't worth the hassle (at least until disaster strikes).

Re:TLS 1.1 or 1.2?

[rsandwick3]

Static-link in some GnuTLS and let M$ decide if IE should join in the fun once it's the only one still giving warnings? Or does it not play nicely with winsock?

Re:TLS 1.1 or 1.2?

[rsandwick3]

I mean not giving warnings, and publicly noted as such...

Re:TLS 1.1 or 1.2?

[Anonymous Coward]

Will you kindly explain to the unwashed masses how you would implement TLS 1.1 and 1.2 support in a world where the dominant library OpenSSL does not yet support either of the protocols in its stable releases? Sure, you can use GnuTLS and mod_gnutls, and I have tried it, but there was no point, as no browser apart from Opera supported it and there were some weird glitches in the module. IE 8/9 were supposed to support them under Vista and 7, but failed to access the site served by mod_gnutls when 1.1 and 1.2 were enabled on the client side. I tried it anew yesterday just out of curiosity, and now even Opera 11.51 chokes on TLS 1.1 and 1.2. So there. Nothing really supports the protocols. Must wait for OpenSSL 1.0.1 for TLS 1.1 and nobody knows when that will hit the repos.

Re:TLS 1.1 or 1.2?

[shish]

OpenSSL (which is what most open source software uses for SSL/TLS support) only supports TLS 1.0 (1.1 support has been added recently but not released) - GnuTLS (which some software can use as a compile-time option, normally defaulting to "off") supports 1.1 and 1.2

Re:TLS 1.1 or 1.2?

[Joce640k]

The point of the fix is that a whole lot of servers are now invulnerable to this.

(Hopefully the important ones).

Re:TLS 1.1 or 1.2?

[Kjella]

AC said it, the standard may be many years old but no released version of OpenSSL supports anything higher than TLS 1.0....

Re:TLS 1.1 or 1.2?

[Kjella]

Could clients detect this somehow and fall back to support the broken behaviour? For example on detection of an unexpected reset.

Yes, but it opens you up to downgrade attacks. If both the client and server claims to support protocol X then it should not be possible to force them to use protocol Y which is considered less secure, even if both support that too. If you have a fully working TLS 1.1/1.2 client and server then all I have to do is cause a reset, the client will think it's a broken server and they'll use TLS 1.0 so you create a vulnerability where there was none.

Re:TLS 1.1 or 1.2?

[Anonymous Coward]

Not much harder than it would have been for them to upgrade from IE 6...

So a couple of years and millions of dollars in new internal and vendor code then? Just to enable TLS 1.2?

Re:TLS 1.1 or 1.2?

[Yaur]

unless the attacker sends a reset when they observe the client claiming to support TLS 1.1/1.2

Re:TLS 1.1 or 1.2?

[Phaeilo]

But if you have to renegotiate down to 1.0 because the server does not support it, you are still vulnerable.

Re:TLS 1.1 or 1.2?

[dachshund]

Its not the only the browsers that need to support the newer versions of these protocols, but also the servers.

Maybe not. It appears that OpenSSL in 0.9.6d implemented a "fix" to TLS 1.0 that may not require a change to the server. The basic idea is that the browser injects message prefixes into the stream as a kind of "fake" IV, to keep the Javascript from having control of which messages get encrypted. This may stop the attack.

Furthermore, if the prefixes are formatted in a certain way --- total speculation --- it may be possible to get the server to filter them out even if it's not running the same software. Anyway, I can't imagine how OpenSSL would implement this fix if the servers don't support it. But I admit I'm just catching up on this aspect.

Here's a brief post describing the "fix":

http://article.gmane.org/gmane.network.openvpn.user/32566

And my speculation on how the attack works, in detail:

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

Re:TLS 1.1 or 1.2?

[Anonymous Coward]

The basic idea is that the browser injects message prefixes into the stream as a kind of "fake" IV, to keep the Javascript from having control of which messages get encrypted. This may stop the attack.

Furthermore, if the prefixes are formatted in a certain way --- total speculation --- it may be possible to get the server to filter them out even if it's not running the same software.

It's been a while since I read the SSL/TLS specs, but are there any "NOOP" records in a TLS packet? The TLS client can send a packet with actual data but also include some random amount of garbage that is ignored by the server. This makes traffic analysis harder since you don't know exactly what's in the cipher text.

SSH does this with the SSH_MSG_IGNORE message type (11.2 in RFC 4253). Could the same be done in TLS?

Re:TLS 1.1 or 1.2?

[Anonymous Coward]

Suppose you're a browser developer...Do you want users to switch to another browser since your software doesn't work with 1-2% of all SSL sites, and the other ones do?

Re:TLS 1.1 or 1.2?

[egamma]

But if you have to renegotiate down to 1.0 because the server does not support it, you are still vulnerable.

Both browsers and servers should both be updated to support TLS 1.1 and 1.2, and both browsers and servers should negotiate the most secure, mutually supported protocols and cyphers.

Adding that support will take some time, and it will take years to lose the old clients that aren't updated (Win XP with IE 6 still has another 2+ years of support, for example). But if we don't start adding support now with backwards compatibility so that nothing breaks then we're never going to get the newer protocols.

Is backwards compatibility less secure? Sure. But if you don't have it, users will either switch to an insecure browser ("if chrome won't let me buy on amazon then I will switch to Internet Explorer"), or they will switch from one ecommerce site to another ("amazon.com doesn't work so I'm going to newegg.com").

Businesses aren't going to let that second scenario happen, and I don't blame them. And surely you agree that the first scenario is even worse?

Re:TLS 1.1 or 1.2?

[ultranova]

I'm sure sites will get upgraded nice and quickly once their customers start telephoning and saying 'my browser gave a scary warning when I tried to enter my credit card details!'

Except, of course, the customers don't do that. They simply figure this is one of the endless list of pointless natter comfirmations computers bombard them with, and click on it until it goes away.

Re:TLS 1.1 or 1.2?

[ewanm89]

the reason 1.1 and 1.2 protocols are more secure is cause they break the backwards capability of the protocol, one can nolonger downgrade to SSL3 or earlier. This means that 'till all servers run 1.0 or higher the browsers can't switch of SSL 3.0 and switch on TLS 1.1 and 1.2.

Re:TLS 1.1 or 1.2?

[Pathwalker]

The general opinion is that the LGPL bars distribution of a statically linked binary containing non-GPL family code combined with LGPL code.

You might be able to get away with providing object code for both your binary and the library, but that makes RMS sad.

Re:TLS 1.1 or 1.2?

[idontgno]

Or, if they have one or two braincells working on critical thinking, they'll wonder and worry, call the support site for the organization whose server they're trying to use, and get told (after waiting on hold for several hours) "that warning doesn't mean anything; your connection is as private and secure as it always has." And that will be that.

If we're gonna hypothesize some kind of public groundswell in support of long-delayed technological deployments, can we get it behind IPv6 first? kthxbye.

Re:TLS 1.1 or 1.2?

[Joce640k]

Presumably the client could warn the user...

Re:TLS 1.1 or 1.2?

[Anonymous Coward]

Have you tried IIS 7.5 and IE 9?

Re:TLS 1.1 or 1.2?

[Anonymous Coward]

I'm not sure whether it's really a prefix. TLS 1.0 (RFC 2246) explicitly states that a variable length (and value) padding may be inserted before encryption.

However, you could also at random moments signal an "encryption algorithm change" and then reuse the same algorithm; that's also unpredictable data which doesn't impact servers.

Re:TLS 1.1 or 1.2?

[chris.alex.thomas]

yeah ok, losing 1-2% market share, wow, hold the phones! mozilla just went out of business!

Acronym hell

[Chrisq]

Having looked up "1.2. FTFA" on google I now feel like a complete idiot

Re:Acronym hell

[DarwinSurvivor]

acronymfinder FTW

Re:Acronym hell

[Joce640k]

Um, none of those are acronyms, they're initialisms.

See: http://lyberty.com/encyc/articles/abbr.html

Re:Acronym hell

[Marc Madness]

...and who says punctuation is not important?

Re:Acronym hell

[dirtyhippie]

Are they initialisms, though? Do you read "FTFA" as "eff tee eff ay" or "from the f*king article" ? Most people I know do the latter, which means its not an initialism either.

Re:Acronym hell

[Anonymous Coward]

But you look natural.

Re:Acronym hell

[DarwinSurvivor]

and yet acronymfinder still finds them...

"throw BEAST off the scent"

[Joce640k]

So....how long before they update BEAST?

Re:"throw BEAST off the scent"

[GameboyRMH]

They'll have to try a completely different approach.

Smart workaround, I didn't know this was possible without changes on the server side.

All the more reason to use a VPN

[jkbull]

If you use a VPN, you should be protected from "local" man-in-the-middle (MITM) attacks. By "local", I mean between your computer and the VPN server. A VPN doesn't protect you from a MITM attack between the VPN server and the webserver you are connecting to. But it does protect you to the VPN server if you are at an Internet cafe, hotel, or other untrusted network.

At least that's true for most VPNs that use software based on OpenVPN, which uses OpenSSL for encryption. A copy of an email from James Yonan was recently posted to the OpenVPN User's list. Bottom line of the email: OpenVPN uses OpenSSL for encryption, and OpenSSL has been patched since 2002 for the vulnerability which most people think is exploited by BEAST. As long as your VPN software uses a patched version of OpenSSL you should be covered, at least for the "local" MITM attack.

For example, VPNs based on Tunnelblick, a free and open source GUI for OpenVPN on Mac OS X is not vulnerable.

Re:All the more reason to use a VPN

[ledow]

I found out all that information for myself separately before you posted that, but it's interesting to see the problem. I had to make the same assumption that the attack described is actually the one that was published all those years ago, which is pretty likely at this stage.

To summarise: Web browsers tend to use the NSS libraries, which have a "bug". The bug is subtle and actually part of the TLS 1.0 standard, but a tiny, standards-compliant, workaround virtually fixes the problem.

It's the same bug that OpenSSL patched 9 YEARS ago, fully knowing what they were patching and based on a publicly available paper on attacking exactly what NSS/OpenSSL were designed for (so the name "Network Security Services" is a bit of a misnomer now). The workaround is pretty basic (throw empty junk into the conversation first) but by all accounts "works".

A lot of browsers use NSS and thus are vulnerable. Some don't and thus aren't (Opera uses OpenSSL which was patched against this 9 years ago!). The "fix" that Google have committed to Chrome is basically identical to the OpenSSL fix from all those years ago.

The bug was pretty much unforeseeable all that time ago, and thus TLS 1.1 etc. were born to supplant it. You can't really blame people for the bug existing in the standard - you CAN blame them for not fixing it 9 years ago when others did exactly that, in "open" code.

Lessons to be learned:

1) SSL library authors needs to READ publicly available exploits aimed at the code they are developing.

2) They need to read other project's bug/commit-logs/security warnings if they are serious about being a competitor to their security.

3) Don't use libraries that don't do the above if you want to be taken seriously, and certainly not in a mainstream millions-of-deployments browser.

4) Update your libraries and recompile your code when they change.

OpenSSL know what they are doing and have a good reputation. NSS are pretty much amateurs. Think of that next time you want to use an SSL library.

Re:All the more reason to use a VPN

[babtras]

All you'd be accomplishing is changing which part of an untrusted network your traffic is carried by. As long as the traffic traverses Internet infrastructure that you don't personally control, it is untrusted and is subject to monitoring. Unless you set up a VPN tunnel to each website you frequent, this will remain a problem. VPN is no answer.

Re:it is not

[Anonymous Coward]

According to a reverse short URL service, that link goes to http://www. hallo mall.com/fashion -accessories/finger- ring.html

spaces inserted to DESTROY that spammer buuuuuuuuuuahaha

Speculation on the attack

[dachshund]

I had posted this in another thread, but in case it's helpful --- this is my best guess on how the attack works in detail:

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

Re:Speculation on the attack

[Anonymous Coward]

That's a pretty accurate description of how the attack works, for anyone who has a decent crypto background.

Confusing it? Really?

[Anonymous Coward]

That doesn't sound like a "fix" as much as it sounds like a "bandaid."

It doesn't counteract the root functionality of the exploit. It simply reduces the chances of it being successful.

It's like changing your windows password every day and calling that "invulnerable security" simply because someone is less likely to be able to guess it.

Re:Confusing it? Really?

[Edgewize]

Although it has not been fully disclosed yet, it's my understanding that the attack is only practical because of a sort of implicit "trust chain" in the implementation of TLS 1.0 where knowledge of one block gives you all the information you need to decode the next block... but also that proper decryption of one block means that you know that you decrypted the previous block successfully. That's the kicker - if you are just making guesses at one block but know the contents of the next block, the encrypted results of the second block are a kind of oracle to see if you got the first block right or not.

Now, if you use javascript to prime the channel with a (block size minus one) byte message, you're going to be able to guess the first byte of the next message and then check to see if you were right using the oracle trick. Once you know that, use a (block size minus two) prefix and guess the second byte. Rinse, repeat until you've grabbed it all, one byte at a time, thanks to the ability to check your guess using the next packet as an oracle.

My layman's understanding of the fix is that it neutralizes the oracle by adding additional variation. This means that you'd have to guess the random variation in order to craft an "oracle" packet that tells you that you guessed the previous packet correctly. Multiply the guessing search space (2^8 possibilities) by the variation and you're up in "computationally infeasible" territory. The attack is thus neutralized.

Re:Great, but OPERA already solves it

[Lennie]

It is only solved for those websites that also support TLS/1.1 and/or TLS/1.2.

There is no GUI which displays what the server supports so you don't really know.

Also like IE8 or IE9 on Vista, Windows 7 and Windows 8 preview-or-whatever-it-is-called it is disabled by default.

As I understand it is disabled by default on IIS too.

Apache on Debian old-stable does not support TLS/1.1 on Debian stable it does. It is enabled too. You can get TLS/1.2 as well, if you install mod_gnutls instead of mod_ssl

So in practise most people are not protected.

Answer: It's NOT - Opera has TLS 1.2!

[Anonymous Coward]

See here -> http://it.slashdot.org/comments.pl?sid=2439924&cid=37478006

APK

Re:Answer: It's NOT - Opera has TLS 1.2!

[Anonymous Coward]

See here -> http://it.slashdot.org/comments.pl?sid=2439924&cid=37478006

APK

No longer true. Hasn't been the case for some time.

Maybe a fucking huge hosts file will fix it.

Re:Answer: It's NOT - Opera has TLS 1.2!

[Anonymous Coward]

I use Opera 11.51, the latest stable release, and it's got tls 1.2 for encryption for ssl sites in it. APK also commenting about Opera's by site prefs and his not using javascript also keeps anyone from being infected by *beast* that way also. Are you on crack or just being a troll?

Don't use those sites then

[Anonymous Coward]

Temporarily @ least, & it's as simple as that: Especially w/ "the BEAST lurking about" on MILLIONS OF SITES now -> http://www.theregister.co.uk/2011/09/21/google_chrome_patch_for_beast/ (not kidding about "millions" either, take a read of that article!).

That's in regards to your point (requoted below) of:

"It is only solved for those websites that also support TLS/1.1 and/or TLS/1.2." - by Lennie (16154) on Thursday September 22, @07:46AM (#37478086) Homepage

Pretty simple... see the above (IF you value your online security & what-not, that is...).

Opera's got the solution already - you just have to utilize it, & it's better than FF is, Chrome possibly too until they release their "fix hack" here. IE's got "advanced encryption" options too though, but not SURE if it's TLS 1.2 or better is all!

---

"Apache on Debian old-stable does not support TLS/1.1 on Debian stable it does. It is enabled too. You can get TLS/1.2 as well, if you install mod_gnutls instead of mod_ssl" - by Lennie (16154) on Thursday September 22, @07:46AM (#37478086) Homepage

Ahem: That's NOT OPERA'S FAULT though - that's the Apache folks... by default @ least.

---

"So in practise most people are not protected." - by Lennie (16154) on Thursday September 22, @07:46AM (#37478086) Homepage

Again, whose fault is that? Not Opera's! It provides a defensive mechanism, when & where it applies (various sites), & all you have to do, is enable it... very simple, & apparently, as-per-Opera's-usual?? BETTER THAN JUST ABOUT ALL OF ITS COMPETITION DO!

APK

P.S.=>

"Also like IE8 or IE9 on Vista, Windows 7 and Windows 8 preview-or-whatever-it-is-called it is disabled by default. As I understand it is disabled by default on IIS too." - by Lennie (16154) on Thursday September 22, @07:46AM (#37478086) Homepage

So again: JUST ENABLE IT in Opera, just as I did... I mean, hey - after all: TLS 1.2's only a button click or two away, just as I noted it in decent enough detail in my reply you responded to here...!

... apk

Re:Great, but OPERA already solves it

[Anonymous Coward]

You can't make this shit up.

Re:Great, but OPERA already solves it

[Anonymous Coward]

Where did you found that selective flashblock in Opera? I have been able to block flash completely (loading again required reloading entire page, with all flash elements), or not at all.

On detecting what a website runs? EASY!

[Anonymous Coward]

Use this (with example, check it) -> http://uptime.netcraft.com/up/graph?site=slashdot.org

"It is only solved for those websites that also support TLS/1.1 and/or TLS/1.2. There is no GUI which displays what the server supports so you don't really know. ... Apache on Debian old-stable does not support TLS/1.1 on Debian stable it does. It is enabled too. You can get TLS/1.2 as well, if you install mod_gnutls instead of mod_ssl" - by Lennie (16154) on Thursday September 22, @07:46AM (#37478086) Homepage

Well, you DO, now...

* AND, via a GUI, no less!

APK

P.S.=> That "overcomes your objections", I'd think, in addition to Opera ALREADY featuring TLS 1.2 as an optional encryption method for SSL (and a LOT MORE I noted in my init. reply that TRULY makes it "a browser built BY WEBSURFERS, for websurfers" (not advertisers &/or large company advertising monies or informational tracking gains))...

... apk

Re:On detecting what a website runs? EASY!

[Lennie]

That does not help, it does not show what version of HTTPS it supports.

The way to check HTTPS versions/protocol features and so on is at:

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

This is what it says on the page:
TLS 1.2 No
TLS 1.1 No

But it obviously still does not tell you if _you_ are connected to a server with supports it and if client and server are using it right now.

Trust me, most don't support it.

The best and most simple way to make sure you are safe is:
- close the browser (all existing HTTPS-connections are thus closed)
- open the browser
- only open a tab/window to the HTTPS-site and don't forget to type https:/// infront of it
- and use that
- when you are done
- logout on the site
- close the browser

Works fine with SSL/3.0 or TLS/1.0

Because what the attacker needs to do is through some other channel inject plain-text into the stream you are using to connect to the HTTPS-site.

The man-in-the-middle attacker does this by modifying a page loaded over HTTP that you loaded on a different page.

If all you have open is the one site, they can not do that.

Use Opera v. 11.51 or better... apk

[Anonymous Coward]

See subject-line above... & THIS is WHY UPDATING YOUR SOFTWARE TO "LATEST/GREATEST EDITIONS" is important - to keep up not only with featureset enhancements, but also security features (like TLS 1.2 in Opera).

* Now, it MAY be in earlier models, but that's the latest "full/stable" edition & I'd suggest updating/upgrading to it on YOUR end... for the purposes of protecting yourself vs. this "BEAST" scripted attack.

APK

P.S.=> Here, THIS link should help on that account so you can get ahold of it (or even the "12" models in 'beta' etc./et al):

http://my.opera.com/desktopteam/blog/

... apk

Uhm, I didn't - what's "made up"?

[Anonymous Coward]

I knew about this 3 days ago in fact, courtesy of this article http://www.theregister.co.uk/2011/09/19/beast_exploits_paypal_ssl/page2.html entitled:

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

(This "pertinent quote/excerpt" from said posting gave me the information I extolled regarding TLS 1.2 (I was using it already though, but, might as well "spread the good word" to others here too I figured!)):

---

"Secure TLS versions are available in its Internet Explorer browser and IIS webserver, but not by default. Opera also makes version 1.2 available"

---

* ... &, there you go!

APK

P.S.=> Incidentally, IF you're "trolling", & I am fairly certain you are with that wise-crack reply? I don't feed trolls... but, I do LOVE "shooting them down in flames" with facts & backing documentations...SO, on that note - what was "made up" (or false/incorrect) in what I posted?

Also, lastly - Why do I get the feeling that "Mr. AC Troll" will run like usual, or begin an off-topic adhominem attack now in effete retaliation, or downmod my posts due to his own FAIL @ trolling me as-per-his-truly COWARD AC trolling replies off topic b.s.?

... apk

Re:Uhm, I didn't - what's "made up"?

[MadMaverick9]

thnx for the link.

on page 1 it says:

BEAST is like a cryptographic Trojan horse - an attacker slips a bit of JavaScript into your browser

how does it do that? and more importantly how can I as a user check if this piece of javascript code is running in my browser (firefox).

do you have any further details on this? thnx.

Re:Uhm, I didn't - what's "made up"?

[Anonymous Coward]

Apart from vomiting up page after page of mental trash, you're not feeding trolls. Right.

Re:Uhm, I didn't - what's "made up"?

[Anonymous Coward]

See, you're even too stupid to understand the meaning of one little sentence of six words.

You're such a waste.

Re:Uhm, I didn't - what's "made up"?

[Anonymous Coward]

I take back what I just said. Sorry APK.

Re:Uhm, I didn't - what's "made up"?

[Anonymous Coward]

Sorry about my last 2 comments APK, I apologize. I take both back.

Try these 2 methods, combined (step-by-step)

[Anonymous Coward]

1.) Tools menu -> Preferences submenu -> Content left-hand-side ribbon item (uncheck them ALL as to javascript, iframes, cookies, & plugins, FIRST - this creates a "global default policy" of ONLY letting those potentially dangerous things run in the 1st place on sites you frequent, or don't frequent & stumble upon/are linked to).

2.) Then, say on YouTube (specifically since it regards FLASH)? Right-click on the page itself... the popup menu has an "EDITSITE PREFERENCES" menu item (use it): There is a CONTENT tab (for plugins & more), COOKIES tab, SCRIPT tab (javascript), DISPLAY tab (iframes/frames), & NETWORK tab (for leaving tracking info. of a sort)).

---

* ... &, there you go - hope that's helpful in using what I feel is the BEST FEATURE of Opera, that other browsers (which are OBVIOUSLY built to cater to advertising & tracking, vs. Opera being "built by websurfers FOR websurfers" instead) don't have, period, afaik (at least NOT by default w/out addons).

APK

Re:Try these 2 methods, combined (step-by-step)

[Anonymous Coward]

wow, thanks! There was an option "enable plugins only on demand", it has either been added recently or i was missing it for a long time, it now acts similarly as flashblock in chrome and firefox.

Re:Try these 2 methods, combined (step-by-step)

[Anonymous Coward]

Chromium: http://i51.tinypic.com/24g3q1e.png

Sure does (you even SAID how)

[Anonymous Coward]

Or didn't you state this in your init. reply to me (verbatim requoting you from it in fact):

"Apache on Debian old-stable does not support TLS/1.1 on Debian stable it does. It is enabled too. You can get TLS/1.2 as well, if you install mod_gnutls instead of mod_ssl" - by Lennie (16154) on Thursday September 22, @07:46AM (#37478086) Homepage

I.E. (per your own words above & a bit of research IF necessary for knowing what servers/webservers contain such SSL encryption abilities, for those concerned unlike yourself because you KNEW some already, & about online safety) E.G.:

IF you know what the server runs OS-wise, & webserver-ware wise (which the netcraft page posted shows you)? Per your OWN WORDS above, you know "what's-what"!

E.G. - How HARD is it to make this query in BING or GOOGLE to research what TLS encryption methods are possible in webservers noted?:

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

(Simply by querying GOOGLE on this quoted string: "Apache" and "TLS 1.2")

?

ANSWER = it's NOT... "here endeth the lesson"

APK

P.S.=> OR, didn't you say that above, AND doesn't netcraft's "WHAT'S THAT SITE RUNNING" NOT SHOW WHAT SLASHDOT.ORG (my practical example) SHOW THE OS & WEBSERVERWARE THIS SITE USES and GOOGLE/BING DO THE REST?

Sure they do - that's what those tools are FOR...

... apk

Re:Sure does (you even SAID how)

[Lennie]

Actually you don't, here is a short list of things from the top of my head:
1. there could be a HTTP-reverse proxy in front handling the HTTPS, so even if the HTTP-header inside the HTTPS instream says it used webserver X. It does not mean your browser is talking directly to that HTTP-server
2. Even if it says: Apache it might not say what version.
3. For Apache it depends on the version of the OpenSSL-library installed and the options need to be enabled. For Debian a default install of Debian stable should be fine as I understand it (haven't checked)
4. A fairly recent Apache with mod_ssl (which uses OpenSSL) like the one in Debian stable supports TSL/1.1, the previous stable does not. Debian stable also has the option to use mod_gnutls instead, it supports TLS/1.2
5. it has to be enabled on the server for it to work, this is the problem with IIS. It is off by default as I understand it (haven't checked)

Re:Sure does (you even SAID how)

[Qzukk]

Netcraft can only tell you what the server is configured to tell it.

See: http://httpd.apache.org/docs/2.2/mod/core.html#servertokens
And: http://httpd.apache.org/docs/2.2/mod/core.html#serversignature
Or, if it's even Apache at all, consider: http://forum.lighttpd.net/topic/3887

Finally, even if you had the version of apache and the server wasn't lying to you, it's the OpenSSL and/or GNUtls library version you'd need to know to actually find out what's supportable, and that still doesn't tell you if the admin disabled specific protocol versions. (ie, Apache/1.3.42 (Unix) mod_perl/1.31 could probably be compiled against libssl 1.0.0 or 0.0.6 for all you know. Assuming it's not lighttpd configured to lie.)

The only way to know what version of SSL/TLS is supported is to connect and ask for decreasing versions until one is accepted.

Ignorant

[glodime]

You're ignorant.

You're welcome.

Re:Ignorant

[neokushan]

You forgot the "here", but thanks for the effort!

Re:Ignorant

[glodime]

Thanks for asking the question though. It was my first thought when I read the /. summary. I learned a bit from the answers.

Re:Ignorant

[neokushan]

Indeed. Slashdot may have gone down in recent years and have a bit of a reputation for trolls and shills, but if you know how to navigate through the comments, it's still a golden source of insight, information and the occasional bit of wit. This comment thread shows that..

Both your method, & mine, DO work... apk

[Anonymous Coward]

The GOOGLE query shows information on Apache versions & TLS 1.2 etc. (after you find what webserverware + server OS, if not versions, is being used for sites in question).

* No questions asked: Per my subject-line above, BOTH methods work, yours AND mine (which is after all, what this IS really truly about: Informing others, & I learned a new trick/tool too here, see below...).

APK

P.S.=> Your tool provides a way, very direct (thanks for the link, it made my favs in fact), but so does mine with a WEE BIT more "legwork" is all...

... apk

Re:Both your method, & mine, DO work... apk

[Anonymous Coward]

WHY must you bold and CAPITALIZE like a raving lunatic? It makes ME (and MANY others here) disinclined to AGREE WITH YOU.

Re:Both your method, & mine, DO work... apk

[Lennie]

Yes, but what does a Google query tell you about the website (thus server) you are connecting to ?

The Google query tells you certain versions of Apache do support TLS/1.1 and TLS/1.2.

It does not tell you the Apache of the website you are connecting to has that version of Apache installed.

Even if it did, it does not tell you what version of OpenSSL is installed. You can compile a new version of Apache with an old version of OpenSSL just fine. And people do (!)

Re:Both your method, & mine, DO work... apk

[Anonymous Coward]

WHY must you go off-topic and TROLL like a raving lunatic? It makes ME (and MANY others here) inclined to DISAGREE WITH YOU

See orig. article 4 starters (& Opera too)

[Anonymous Coward]

As to details, but, IF you look at my link here (on javascript specifically since you noted it) -> http://it.slashdot.org/comments.pl?sid=2439924&cid=37478726 as it shows how to DISABLE javascript GLOBALLY (1st step in detail too) & then, BY SITE individually as you need features to activate them via its "By Site" exceptions list ability, on how to set web 2.0 featuers, albeit ONLY ON SITES YOU ABSOLUTELY NEED IT ON (which is unique to opera really as far as being "built in natively into a webbrowser" for the most part afaik & what I truly LOVE about it the most - mainly because this bolsters not only SECURITY, but, also SPEED (since you're not activating things you do NOT need to be running using up CPU/RAM/Other forms of I-O too)).

In fact, try it sometime as an experiment!

E.G.-> Block out:

A.) adbanners
B.) popups
C.) plugins
D.) scripts
E.) iframes/frames
F.) cookies

etc.-et al

AND, watch how FAST sites load & run (much faster than with them active, especially IF you do NOT really need them - you do in plugins on say YouTube, &/or say, javascript for DataBase accesses on ecommerce sites), but otherwise? You don't, not really (unless you personally feel otherwise)...

See - I do that here on /. for example!

( & it FLIES by comparison to letting them run! I don't need them is why, & again - they CAN be a possible potential security-hazard (per your own point you made on this exploit being foisted upon users via javascript usage online... which for a decade++ now, it's been known as such a risk/double-edged sword...)).

NOW, finally, lol, as to your question here:

"how does it do that?" -

Well, hate to say it, but... if you run javascript actively w/ no preventative cutoffs (especially in FF, since it has no TLS 1.2 implementation currently per what those articles say?)

YOU let it happen... and of course, the webmasters who run those sites have not updated to mod_ssl updates for TLS 1.2 on Apache (& other webservers for example, though IIS implements it, but NOT BY DEFAULT - this is the webmasters' responsibility!).

APK

P.S.=> And, you're most welcome (for your thanks) but... this was about learning & I even got a "new trick/tip/technique/tool" from another replier here, Lennie (can't beat that - it's NOT a "wasted day" IF you learned a new thing I figure), so... "glad to be of assist" here!

... apk

Lennie, the NETCRAFT link I put up does... apk

[Anonymous Coward]

Come on Lennie, you're better/smarter than THAT!

"Yes, but what does a Google query tell you about the website (thus server) you are connecting to ?" - by Lennie (16154) on Thursday September 22, @11:01AM (#37480096) Homepage

It tells you what mods or webserver builds (in the example I used, Apache) contain TLS 1.2 or what mod is necessary for it to work (you even noted which does iirc).

The articles tell you IIS has better encryption also, but NOT BY DEFAULT, you have to activate it...

You have what you need with the 2 pieces I supplied, just a touch more "legwork" (not exactly 'brain-surgery' either mind you) than your direct method is all... but, again:

I am SURE that if I can "figure that out"? So you can you, & others... using NETCRAFT's What's the site running link I supplied, & the GOOGLE query I put up after in reply to you!

E.G.-> http://uptime.netcraft.com/up/graph?site=slashdot.org

&

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

---

"The Google query tells you certain versions of Apache do support TLS/1.1 and TLS/1.2. - by Lennie (16154) on Thursday September 22, @11:01AM (#37480096) Homepage

Again, see the above: My 2 steps do what your site you pointed out does, not a hell of a lot more detective work is all... BOTH methods work, yours & mine, easily (& It doesn't take a "brainiac" to use either one).

---

"It does not tell you the Apache of the website you are connecting to has that version of Apache installed.by Lennie (16154) on Thursday September 22, @11:01AM (#37480096) Homepage

AGAIN, Lennie, come on man - read it closely:

NETCRAFT DOES TELL WHAT APACHE YOU CONNECT TO, see my example, look @ IT CLOSELY:

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

E.G.=> SLASHDOT USES APACHE 1.3.42 & then you can inquire with the guys here (they do, after all, supply contact info.), IF needed... pretty simple!

APK

P.S.=> HOWEVER, the topic & ARTICLE @ hand, is browsers specifically, not servers (see subject of this article, Chrome specifically).

Thus, I supplied what others thanked me for in part in other replies, that Opera already HAS WHAT IS NEEDED, browser-side, in TLS 1.2... the bottom-line here AND TOPIC, is that above all else!

... apk

Re:Lennie, the NETCRAFT link I put up does... apk

[Lennie]

The point I'm trying to make is, the version number of a webserver does not mean that TLS/1.1 or TLS/1.2 will actually be used when your browser connects to it.

As I pointed out before, as an example:
IIS (the Microsoft webserver on Windows Server) has the ability to use TLS/1.1 and TLS/1.2 but it is not enabled by default.

Just that case makes it pretty clear that a version number alone does not tell you anything.

It doesn't matter if your browser support TLS/20.234 or whatever, if the server does not support it. It can't use it.

We should probably just agree to disagree.

You're welcome

[Anonymous Coward]

See subject-line above & thank you for the thanks!

APK

P.S.=> I had to thank someone for supplying me a direct tool here too, in Lennie's replies in fact, for an online analysis tool he provided myself (& others) here in fact - NOT A "WASTED DAY" if you learn a new thing I figure!

His tool (vs. my 2-3 step detective work methods), saves a few seconds of work actually!

(Yes, I can do that with a couple more steps for the most part, via:

NETCRAFT'S "What's that site running" -> http://uptime.netcraft.com/up/graph?site=slashdot.org

&

A simple GOOGLE or BING query -> http://www.google.com/search?sclient=psy-ab&hl=en&site=&source=hp&q=%22Apache%22+and+%22TLS+1.2%22&btnG=Search on webserver(s) that have TLS 1.2 abilities)...

So... you MAY wish to look into Lennie & my "exchange/debate"!

He illustrated good tools are there for you to use also that combine with Opera's TLS 1.2, & "By Site Prefs" abilities (unique to Opera in fact afaik & native to it) to secure yourself vs. this threat, & identify (especially for your FAV sites you frequent most) which sites have TLS 1.2 abilities in their webservers (IF NEED BE? Well - You can email the folks here on a site too asking on their TLS level if needed, or use Lennie's tool here -> https://www.ssllabs.com/ssldb/analyze.html?d=slashdot.org&s=216.34.181.45 )...apk

Re:You're welcome

[Anonymous Coward]

Masturbating over one "thanks" again? Still no mod-up? Poor APK.

Re:You're welcome

[Anonymous Coward]

More offtopic trollery? Poor troll. Nobody thanks U 4 trolling and apk was thanked more than once dumb ass http://it.slashdot.org/comments.pl?sid=2439924&cid=37479604 and in addition to the one you refer to now. Learn to read and count.

Solutions without TLS v1.1 and v1.2

[tmshort]

Based on what is known about this attack, there are a number of ways it can be thwarted without the need for TLS v1.1/v1.2.

1. Google's solution: by randomly sizing the TLS records, this adds randomness to the known plaintext through more frequent padding.

2. OpenSSL's solution of refreshing the IV by adding an empty TLS record - but some MS products have issues with this.

3. TLS v1 permits up to 255 bytes of padding. Most implementations add the minimum amount (up to 7 for 3/DES and 15 for AES). Using a random amount of padding adds randomness to the known plaintext, in a manner similar to, but different than, Google's solution.

4. Use HTTP/1.0. The suspected attack vector requires a long-term TLS connection that is reused by the browser. HTTP/1.0 allows one request per connection. Each connection will use different key material. This means that BEAST's JavaScript request will have different keys than the user's request. This is easily configurable on the server, and requires no changes to the client (unlike solutions 1-3).

The trade-off is that all these options slow down the connection to some degree.

Re:Solutions without TLS v1.1 and v1.2

[raynet]

Could the server use compression and randomly vary it and not do optimal gzipping for the content?

Re:Solutions without TLS v1.1 and v1.2

[tmshort]

It's apparently an issue with the client-sent data - that is the data that is analyzed. BEAST has no control over the server-sent data, so whatever the server does, short of closing the connection, has no effect.

Re:Solutions without TLS v1.1 and v1.2

[raynet]

Can clients send compressed data to servers?

Re:Solutions without TLS v1.1 and v1.2

[tmshort]

Strictly-speaking, I don't believe so. There's no way to negotiate the compression method. In the case of the server sending data, the client is able to indicate acceptable compression algorithms (via Accept-type headers) before the server sends the data (with Content-Encoding headers indicating compression). With the client sending data first, there's no way for the server to tell the client what is acceptable.

SSL does have support for compression, but there are no compression methods defined other than NULL.

Re:Solutions without TLS v1.1 and v1.2

[mzs]

Somebody please mod this up.

MAIN point is browsers (see article topic)

[Anonymous Coward]

See subject-line above, 1st. Our methods determine what's needed SERVER-SIDE though that isn't the topic here for end users to make decisions to keep visiting the site or not (a good measure) until their fav. sites especially are "patched proofed" vs. BEAST script (important, SCRIPT especially) & to see IF it has webserver-ware that is capable of better than TLS 1.1.

Best part is though & what users have thanked me for twice here already, e.g.:

http://it.slashdot.org/comments.pl?sid=2439924&cid=37479604

&

http://it.slashdot.org/comments.pl?sid=2439924&cid=37480482

IS THAT OPERA CONTAINS WHAT IS NECESSARY, BROWSER-SIDE, TO COMBAT THIS FROM AN END-USER PERSPECTIVE in BOTH SCRIPTING DEFENSE BY SITE, AND TLS 1.2 "BUILT-IN NATIVELY" BROWSER SIDE, THE TOPIC @ HAND IN THIS ARTICLE NO LESS (& the topic/article IS about browsers Lennie, NO questions asked!).

APK

P.S.=> However - Since you insist on "server-side" end of things though & I agree, that's the "other side of the equation" & the end user has NO CONTROL OF IT unless you do as I do, omit javascript, the deliverer of this BEAST ATTACK (which, because I do that, I am "proof" to)?

You & I both have methods of determining it, + a simple email to the admins of a site (most answer readily, OR, they can use your tool for determining the SSL TLS levels etc. OR mine via NETCRAFT + GOOGLE) does the rest in combination with my method of "detective work"...

Above ALL else here/lastly/in closing:

It's not a matter of "disagree", it's a matter of SHARING VALID INFORMATION for protecting ourselves (and others that read this) imo...

Fact is - I think we both "DID GOOD" in fact, & I never disagreed with you man... you're only covering the "other 1/2 of the equation" server-side is all!

So, again, thanks for a decent inspection tool online (saves me time & detective work to a small degree is why)

... apk

WRONG - there's OTHER WAYS

[Anonymous Coward]

See Lennie & my exchange here: He showed a tool that directly determines what SSL level is being run by webservers/sites

(Servers aren't the topic here & an end user can't control THAT, except for warning sites via email, forums, etc., since its server-side & the article's about browsers, but important nonetheless).

Still - I showed other LESS DIRECT means, but they do work.

WOULDN'T MATTER FOR ME ANYHOW, I CAN'T BE "HIT" BY "BEAST" as I do NOT use javascript online & have been warning others on it for decades -> http://www.google.com/search?sclient=psy-ab&hl=en&site=&source=hp&q=%22HOW+TO+SECURE+Windows+2000%2FXP%22&btnG=Search

Mainly & obviously, because of its unfortunate "double-edged sword nature" like ANY scripted document format's been shown to be a security-risk not only online, but locally too (e.g. Office documents via AutoExec macros, or, Adobe Acrobat javascript usage by default).

NOW - You "bring up a point" though - on "servers lying" which MIGHT invalidate Lennie's tool...

So, my suggestion & method's "3rd optional step" of emailing admins of a site on SSL/TLS levels in webservers MIGHT be necessary as well IF ONLY TO WARN THEY to update mod_ssl, which in the case of my examples (/. mainly this site)? Is available.

APK

P.S.=> I have other methods I noted vs. Lennies, take 1-2 more steps, but would work just the same (NETCRAFT, GOOGLE QUERY, & emailing a site admin IF needed), for server-side (off topic though it is, it matters)...

STILL, bottom-line on what a USER can control to "proof themselves" vs this AND OTHER ATTACKS GALORE?

The topic was BROWSERS here anyhow, so I extolled Opera's "main virtues" & others here thanked me for it (since 1 proofs you completely which I noted above on scripting & the other works with PROPERLY modded servers for TLS SSL encryption (Apache mod_ssl levels, & IIS have it))... apk

APK wins again?

[Anonymous Coward]

They modded ya down and ya ran off with Opera 1.2 tls and javascript advice in not using it because this attack uses it like many to most do.

Aha, ABOUT TIME/Finally... apk

[Anonymous Coward]

I used older builds of "CHROMIUM" before the "latest/greatest" @ least, & never saw that in them earlier this year.

As proof of that in fact, I offer this where I noted that to a poster here named "SanityInAnarchy" who FAVORED Chrome @ least (not Chromium strictly), here:

http://it.slashdot.org/comments.pl?sid=2282088&cid=36680246

Thus, as you can see? Yes - I tried it before myself & never noted it had "exceptions" & I also said that SanityInAnarchy OUGHT TO PROGRAM THAT INTO Chrome/Chromium in fact (since he codes as do I) but, he never answered on that though I "nagged he" on it...

Which is also how/why I was able to comment on Chrome/Chromium speed, in my init. post here as well!

Only "ISSUE" I might have with Chrome especially now (not so much Chromium) is the PRIVACY things I keep hearing from others on it, such as this one:

http://news.slashdot.org/comments.pl?sid=2437606&cid=37460870

From others...

APK

P.S.=> This is actually good news, because I stated I wished other browsers did that, because IE doesn't this is for sure... & iirc, FireFox doesn't as completely on as many things NATIVELY as does Opera either!

... apk

Re:Aha, ABOUT TIME/Finally... apk

[Anonymous Coward]

That option must be enabled in Chrome/Chromium under the about:flags page :). Lots of cool stuff there.

Re:Time 2 have fun w/ an off-topic troll... apk

[Anonymous Coward]

The degree of bullshitism you exhibit is observable by anyone. No PhD required.

Re:Time 2 have fun w/ an off-topic troll... apk

[Anonymous Coward]

I'm sorry about my comment above APK. I apologize and take it back for my bullshitism in it.

Re:Time 2 have fun w/ an off-topic troll... apk

[Anonymous Coward]

U FAIL vs apk again coward troll. No wonder U post ac. U constantly lose to apk.

Re:Time 2 have fun w/ an off-topic troll... apk

[Anonymous Coward]

The degree of trollism you exhibit is observable by anyone. No PhD required

Opera has a GUI TOOL (View menu, dev tools)

[Anonymous Coward]

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

* Opera again "FTW"...

APK

OPERA HAS A SECURITY-CHECK GUI!

[Anonymous Coward]

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

* Opera 11.51 again "FTW"...

APK

P.S.=>

"There is no GUI which displays what the server supports so you don't really know." - by Lennie (16154) on Thursday September 22, @07:46AM (#37478086) Homepage

Actually, I do know because of Opera... & Opera 11.51 has a "GUI TOOL" FOR IT, BUILT INTO OPERA, NATIVELY... see above!

... apk

Opera 11.51 also has a SITE CHECK GUI

[Anonymous Coward]

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

* Opera 11.51 again "FTW"...

APK

P.S.=> So much for you "naysayer trolls", vs. myself, as-per-usual - you KNOW I just GOTTA SAY IT: This? This was just "too, Too, TOO EASY - just '2EZ'"...

... apk

Opera 11.51 has a dev tool natively too!

[Anonymous Coward]

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

* Opera 11.51 again "FTW"...

APK

P.S.=>

"The only way to know what version of SSL/TLS is supported is to connect and ask for decreasing versions until one is accepted." -by Qzukk (229616) on Thursday September 22, @12:39PM (#37481460)

Actually, I do know because of Opera... & THERE IS (again) A "GUI TOOL" FOR IT, BUILT INTO OPERA, NATIVELY... see above, OR the tool Lennie noted here:

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

Take your pick (but again, me? I cannot, absolutely CANNOT be "hit" by this "BEAST" attack, or any delivered via javascript (like so many are), because again?? I DO NOT USE IT, period (it's not trustworthy, especially nowadays)...

... apk

Re:Opera 11.51 has a dev tool natively too!

[Qzukk]

Actually, I do know because of Opera... & THERE IS (again) A "GUI TOOL" FOR IT, BUILT INTO OPERA, NATIVELY.

So your browser connected to the server itself and checked specifically for the supported protocol versions, just like I said. Did it really take three replies to agree with me?

I was simply pointing out that you can't tell just from a server version string because the server version string can be faked, and even when it's not faked, it still doesn't tell you enough information about the supporting SSL libraries and disabled/enabled protocols in the server configuration.

Re:Opera 11.51 has a dev tool natively too!

[Anonymous Coward]

You're agreeing with apk. He points out using browsers n sites before you to check tls\ssl levels.

Not using javascript immunizes me too, lol!

[Anonymous Coward]

Care to disagree with that too? Good luck - you'd need it: Face it boy: You don't have the intellect to get the best of me, on anything in computing (which is why you're an unknown "ne'er-do-well").

"So your browser connected to the server itself and checked specifically for the supported protocol versions, just like I said. Did it really take three replies to agree with me?" - by Qzukk (229616) on Sunday September 25, @08:25AM (#37507338)

I pointed out the built into Opera method & the other tool posted by Lennie does it also:

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

As do my other "detective methods", but... the POINT OF THE ARTICLE/TOPIC is BROWSER-SIDE STUFF dolt!

Thus? Opera, a webbrowser, has TLS 1.1/1.2 built into it, as well as "BY SITE PREFERENCES/EXCEPTIONS" for javascript, iframes/frames, cookies, plugins, etc. (Face it - which is ENOUGH TO IMMUNIZE A USER vs. THE "BEAST" ATTACK, period!).

APK

P.S.=> And, you KNOW IT, and thus, "U FAIL"... period!

... apk

Re:Not using javascript immunizes me too, lol!

[Qzukk]

I never said anything about whether you were insecure or not. The only thing I said was that it was not possible to determine the version of SSL a site uses simply by looking at the server version string, which is what you implied here:

Use this (with example, check it) -> http://uptime.netcraft.com/up/graph?site=slashdot.org [netcraft.com]

How HARD is it to make this query in BING or GOOGLE to research what TLS encryption methods are possible in webservers noted

Because the server can lie about its version, or a server that normally supports TLS1.x could have TLS1.x disabled manually, or a server could use an alternate library like apache+gnutls (which supports TLS1.1 and 1.2) instead of apache+openssl (which does not). The only way to know for sure is to connect directly to the server and try different versions to see which are accepted.

Hold on, you may be right... apk

[Anonymous Coward]

"I'm sorry about my comment above APK. I apologize and take it back for my bullshitism in it." - by Anonymous Coward on Friday September 23, @10:15AM #37491068)

No need to apologize, DEAR Mr. AC.

I MUST admit my writing style is on a graduate school lvl sometimes. The doctors told me I NEED 2 take my medication, but sometimes I JUST FORGET.

(Those STUPID little pills sometimes.... lol!)

--

So /w that said, I APOLOGIZE for torturing all of u with my troll posts.

P.S.: => LOL, pills just dropped on the floor again. ... apk

POOR attempt @ imitating me again... apk

[Anonymous Coward]

You didn't sign off as "APK" in caps @ the end... see below next:

APK

P.S.=> First you apologize to me (for your being a completely off topic illogical ad hominem attack using troll), & now you try to imitate me? Please... get your head on straight and telling others I take "meds" during your imitation? Puh-leese - you're just projecting your own weaknesses once again...!

... apk

Sorry for impersonating you apk

[Anonymous Coward]

See subject above and post I replied to (where I project my problems onto apk).

Re:Sorry for impersonating you apk

[Anonymous Coward]

Do you ever get tired replying as "non-APK", APK? It's not as if your writing style didn't stick out in just one sentence.

You're one sorry existence.

Re:Sorry for impersonating you apk

[Anonymous Coward]

I'm sorry for impersonating you APK. I went back to just plain ac posts now.

2 ways to verify SSL TLS level of a site

[Anonymous Coward]

That I already noted here, many times now (in addition to be "javascript immune" on my end):

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

OR BUILT IN TOOLS IN OPERA 11.51 CAN DO THE SAME:

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

APK

P.S.=> Then, if a site "passes muster" on those 2 tools methods (if not triple checking by emailing a webmaster on it) for SSL + TLS check? You also can feel safe that OPERA ALSO HAS BUILT-IN (optional by default) TLS 1.2 LEVEL SSL ENCRYPTION...

Though immunizing yourself via not using javascript @ via Opera "By Site Preferences" exceptions in combination with its GLOBAL POLICIES (set all cookies, iframes, javascript, plugins, etc. OFF, 1st) all stops you from getting "beast infected" @ all, period... apk

Re:2 ways to verify SSL TLS level of a site

[Qzukk]

So now we're back to where you agreed with me and you're using tools that connect to the server and try different protocols to see which ones work instead of trying to google for the server name to guess what versions might be supported.

I never "agreed" with you.

[Anonymous Coward]

I point out 2 tools that determine TLS levels (in Opera or a website), Opera TLS 1.2 is built into it natively as an optional encryption method for TLS/SSL communication and that disabling javascript immunizes one completely from the "BEAST" attack in the 1st place. This is all I did. You did not point out any tools of the nature I did, nor did you point out a browser that does TLS 1.2, nor that javascript disabling on sites immunizes one from this attack ( & MANY others).

APK