Beta
×

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

Thank you!

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

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

BREACH Compression Attack Steals SSL Secrets

Unknown Lamer posted about a year ago | from the mod-gzip-considered-harmful dept.

Encryption 106

msm1267 writes "A serious attack against ciphertext secrets buried inside HTTPS responses has prompted an advisory from Homeland Security. The BREACH attack is an offshoot of CRIME, which was thought dead and buried after it was disclosed in September. Released at last week's Black Hat USA 2013, BREACH enables an attacker to read encrypted messages over the Web by injecting plaintext into an HTTPS request and measuring compression changes. Researchers Angelo Prado, Neal Harris and Yoel Gluck demonstrated the attack against Outlook Web Access (OWA) at Black Hat. Once the Web application was opened and the Breach attack was launched, within 30 seconds the attackers had extracted the secret. 'We are currently unaware of a practical solution to this problem,' said the CERT advisory, released one day after the Black Hat presentation."

cancel ×

106 comments

Sorry! There are no comments related to the filter you selected.

Wow (0)

Anonymous Coward | about a year ago | (#44481903)

Wow, my jaw is on the floor

NSA go talk to those CERT boys!!! (2)

icebike (68054) | about a year ago | (#44481915)

Those guys are giving away all your exploits.

Re:NSA go talk to those CERT boys!!! (1)

ls671 (1122017) | about a year ago | (#44482527)

Already done the talk a long time ago.

Piece of Cake (2)

rotorbudd (1242864) | about a year ago | (#44481919)

Lets see, gotta have man in the middle AND requires the attacker and victim to be on the same network.
Piece of cake!

Re:Piece of Cake (2)

Manfre (631065) | about a year ago | (#44481937)

Lets see, gotta have man in the middle AND requires the attacker and victim to be on the same network.
Piece of cake!

If some one manages to wire in to my network, they won't need to bother with this exploit. They'll have a lot more access.

Re:Piece of Cake (1)

ls671 (1122017) | about a year ago | (#44482571)

Wouldn't just one compromised machine on your wired network fit the bill?

Re:Piece of Cake (1)

imikem (767509) | about a year ago | (#44482725)

Not on a switched network unless you get on a specially configured port. It has been a long time since most wired networks had shared access. Wireless however is generally a shared medium.

Re:Piece of Cake (1)

skids (119237) | about a year ago | (#44483127)

It's actually rather rare, even these days, for a switched network to be properly configured to protect against MAC flooding attacks. Actually, it's probably more common in enterprise setups for the WiFi to be more secure than the wired, since WPA-Enterprise is getting pretty common.

Re:Piece of Cake (1)

TheRaven64 (641858) | about a year ago | (#44484239)

If you have a managed switch, sure. If you have a cheap OTS switch, then you won't even get a notification that one of the nodes is doing an ARP flooding attack on the switch...

Re:Piece of Cake (0)

Anonymous Coward | about a year ago | (#44482983)

Don't worry, not like everybody uses SSL vpns on untrusted networks or anything.

Re:Piece of Cake (3, Insightful)

Anonymous Coward | about a year ago | (#44481949)

Yeah, no worries, 'cause the infrastructure providers and their NSA buddies aren't in the middle.

Re:Piece of Cake (0)

Anonymous Coward | about a year ago | (#44482149)

Same network? Like the internet?

Re:Piece of Cake (3, Funny)

Score Whore (32328) | about a year ago | (#44483321)

Same network? Like the internet?

*head explodes*

WTF? Do you happen to know the etymology of "internet"?

Re:Piece of Cake (0)

Anonymous Coward | about a year ago | (#44488301)

What does eating insects have to do with the internet?

Re:Piece of Cake (0)

Anonymous Coward | about a year ago | (#44486011)

No. Not like the internet.

Re:Piece of Cake (1)

DarkOx (621550) | about a year ago | (#44482277)

I might be missing the obvious but I don't see the *need* to be on the same network. A couple nailed up ARP entries on your next hope router, a nailed up arp on a separate router with some NATs all at your ISP should enable your favorite three letter agency to this from the comfort of their Washington offices.

Re:Piece of Cake (5, Informative)

phantomfive (622387) | about a year ago | (#44482689)

Here's the list of requirements from CERT. All of these must be true for the attack to work. From this list, a creative person could think of many ways a website could avoid this exploit, but it's harder for the client.

1. HTTPS-enabled endpoint (ideally with stream ciphers like RC4, although the attack can be made to work with adaptive padding for block ciphers).
2. The attacker must be able to measure the size of HTTPS responses.
3. Use of HTTP-level compression (e.g. gzip).
4. A request parameter that is reflected in the response body.
5. A static secret in the body (e.g. CSRF token, sessionId, VIEWSTATE, PII, etc.) that can be bootstrapped (either first/last two characters are predictable and/or the secret is padded with something like KnownSecretVariableName="".
6. An otherwise static or relatively static response. Dynamic pages do not defeat the attack, but make it much more expensive.

Re:Piece of Cake (4, Informative)

viperidaenz (2515578) | about a year ago | (#44482891)

Client protection is simple. Disable HTTP content compression using the Accept-Encoding HTTP request header.

Re:Piece of Cake (1)

phantomfive (622387) | about a year ago | (#44483681)

ok, how do you do that? Or are you talking about a source code modification?

Re:Piece of Cake (2)

Anonymous Coward | about a year ago | (#44483913)

go to about:config in and modify the setting for network.http.accept-encoding?

Re:Piece of Cake (0)

Anonymous Coward | about a year ago | (#44484891)

it says "gzip, deflate"
what do i modify it to? false?

Re:Piece of Cake (4, Informative)

Anonymous Coward | about a year ago | (#44485141)

what do i modify it to?

gzip;q=0,deflate;q=0

Re:Piece of Cake (0)

Anonymous Coward | about a year ago | (#44491857)

It would be better if, as a client, you could disable it for SSL but keep it for unencrypted connection. With many pages, it can make a sizable difference and there isn't really security implication of leaving it for plain text.

Re:Piece of Cake (0)

Anonymous Coward | about a year ago | (#44483105)

wifi at Starbucks, etc?

Re:Piece of Cake (1)

pmontra (738736) | about a year ago | (#44483351)

Any public wifi network will do, at restaurants, conferences, trains, airports etc. Remember firesheep? Where that worked this will work too.

So what exactly is required for this to work? (0)

Anonymous Coward | about a year ago | (#44481941)

The last attack required that the attacker pwn the server and install malicious javascript on the page that would send tons of data between the client and the server so that the attacker could watch the traffic. Which I guess could be easier than just pwning the server and getting the secret data from it.

It's not clear to me how this attack works outside of a lab. Someone MITMing SSL would either break the certificate chain and read the data directly, or not break the certificate chain and not be able to communicate with the server. From the linked description, somehow they are directing the browser to a URL like somesite.com/trysecret=aaaaaaaaaaaaaaaaaaaaaaaaaa and playing a mastermind-like game where if the packet is shorter due to the string in the URL compressing with the string in the cookie, they know they have X characters in a row correct, but not which ones. When they get all 32 characters in a row, they win your sessionID.

So... how do they get my browser to initiate all these requests?

Re:So what exactly is required for this to work? (2)

mstefanro (1965558) | about a year ago | (#44482045)

They just make you visit a malicious website, at which point they can force you to make as many HTTPS requests as they want. They use img src IIRC.

Re:So what exactly is required for this to work? (0)

Anonymous Coward | about a year ago | (#44482143)

> They use img src IIRC

the bytecode can be anywhere, yeah

Verisign Insurance (1)

nemesisrocks (1464705) | about a year ago | (#44481943)

Perhaps Verisign can offer some form of overpriced "insurance" to make customers feel safer on the Internets. I'm sure it'll be thrown in for "free" with a "SecureSite Ultimate" package, for a mere $1500! GoDaddy will no doubt follow suit.

Disable compression? (-1)

Anonymous Coward | about a year ago | (#44481969)

Wouldn't disabling SSL compression invalidate this attack method just like it does to CRIME?

Re:Disable compression? (0, Insightful)

Anonymous Coward | about a year ago | (#44481979)

Nevermind. RTFA for explanation.

Re:Disable compression? (4, Funny)

The Wild Norseman (1404891) | about a year ago | (#44482813)

Nevermind. RTFA for explanation.

See? Text compression in action!

WiFi (1)

the eric conspiracy (20178) | about a year ago | (#44481981)

So if sounds like this could be practical on a WiFi network??

To prevent these sorts of attacks (0)

Anonymous Coward | about a year ago | (#44482003)

We simply need more surveillance.

Seems pretty dangerous (5, Interesting)

mstefanro (1965558) | about a year ago | (#44482017)

This is quite an ingenious attack, but I am very surprised it has taken people so long to find it, as it is very straightforward and easy to understand conceptually. Makes you wonder "how did I not think of that".

Although it may seem like the requirements of a successful attack are difficult to achieve, this may not be the case.
It is usually very easy to inject some plain-text in the source code of webpages.

On facebook:
https://www.facebook.com/photo.php/INJECT_WHATEVER_YOU_WANT_HERE/ [facebook.com]
If you view the source of that URL you can see the text "INJECT_WHATEVER_YOU_WANT_HERE" appears 3 times in the source code.
By appending the query string, on youtube:
https://www.youtube.com/watch?v=hLkugwOYbFw&INJECT_WHATEVER_YOU_WANT_HERE [youtube.com]
And on google:
https://www.google.com/?INJECT_WHATEVER_YOU_WANT_HERE [google.com]

That means that an attacker can extract secret information from a lot of the HTTPS pages that you're visiting.

When I first read about this attack, the first fix that came into my mind was to just append /* [random text of random size] */ to all text/html responses.
  But this may cause troubles: if the random padding is too large, the purpose of compression
is defeated. If it is too small, workarounds may be found.

Maybe it is time to start thinking of algorithms that perform compression and encryption together, not separately?

Re:Seems pretty dangerous (0)

BoRegardless (721219) | about a year ago | (#44482081)

Who said the Eastern European or Russian or Chinese or N. Korean government hackers had not already been using this?

Re:Seems pretty dangerous (1)

mstefanro (1965558) | about a year ago | (#44482255)

Are the governments doing more powerful research than the rest of the world combined?

Re:Seems pretty dangerous (0)

Anonymous Coward | about a year ago | (#44482575)

Is the specific organization that first alerted the public about this exploit doing more research than the rest of the world?

Re:Seems pretty dangerous (0)

Anonymous Coward | about a year ago | (#44483169)

No. Just more focused.

Re: Seems pretty dangerous (0)

Anonymous Coward | about a year ago | (#44482105)

The people who didn't think about it were the same people who designed SSL in the first place -- does that answer the 'why' Question?

Re: Seems pretty dangerous (4, Informative)

mstefanro (1965558) | about a year ago | (#44482163)

This attack has little to do with SSL itself or the cryptosystems used. It's more about the preservation of size when encrypting. Combined with compression, information about the amount of entropy in the plaintext is leaked. If you are allowed to manipulate parts of the plaintext a lot of times, then amount of entropy leakage provides with an answer to the question "does the injected substring appear anywhere else in the plaintext?".

Re:Seems pretty dangerous (0)

Anonymous Coward | about a year ago | (#44482503)

SO,how about fixing the compression ratio and padding more when compression is more efficient to mask the actual secret?

Re:Seems pretty dangerous (1)

Rockoon (1252108) | about a year ago | (#44482773)

SO,how about fixing the compression ratio and padding more when compression is more efficient to mask the actual secret?

..and what ratio would that be?

You seem to be thinking that everything can be compressed.

Re:Seems pretty dangerous (2)

rtb61 (674572) | about a year ago | (#44482909)

Of course is a shift to a broadband world, simply drop the compression and just go with the encryption. If your are compressing to save bandwidth and then padding to secure the compression, which not only takes up bandwidth but initial compute cycles, simply drop the compression and cut out the point of attack.

Re:Seems pretty dangerous (3, Insightful)

complete loony (663508) | about a year ago | (#44483229)

So web servers need to disable gzip & deflate compression on any https page that might contain something sensitive? Sounds like an easy enough fix to me.

Re:Seems pretty dangerous (1)

ArsenneLupin (766289) | about a year ago | (#44485109)

And cookies would be protected (normally...) as they are included in the header (not compressed) rather than the body.

Re:Seems pretty dangerous (0)

Anonymous Coward | about a year ago | (#44483511)

THIS, exactly. All security is obscurity and irrelevance, no better than obsfucation. This is not about compression, but about randomizing compression, the price is small to iron out this intelligence that is available in the size of the response.

Sending secrets again (0)

Anonymous Coward | about a year ago | (#44482041)

Compressing the same secrets many times along with user data repeatedly seems like a bad idea. I know its really easy to point that out now, but this isn't a new issue.

I'm not clear on the details, so this is just my guess at how it really works:
So the issue here is you can be caused to send your secret (a cookie) millions of times adjacent to the injected data and monitor some side channel (size, or timing I suspect).

How about we don't send the same secret every freaking time? Maybe sign the message with the secret, or just trust that the darn TLS session is doing its job? Any time your client can be made to send a secret a ton of times it should set off a red flag. Web dev always seemed like a horrible mess to me: secret tokens that you send with messages is a horrible approach to just about anything, even if the channel is encrypted.

We (the sane) already agree how credit card numbers and passwords are used on the web is stupid (here, let me send you my secret so you can tell who I am/impersonate me). These cookies are the same stupid shit all over again with the same problems, and we are stuck with them for the foreseeable future for legacy reasons. Its a solved problem in cryptography (SRP for passwords, use public key crypto and hashes to sign credit card transaction requests etc). I hate this.

Re:Sending secrets again (1)

mstefanro (1965558) | about a year ago | (#44482075)

Some information simply does not change from one request to the other. In case of facebook, my name appears on the top blue bar on every page. An attacker can therefore extract my name using this technique.

Re:Sending secrets again (1)

viperidaenz (2515578) | about a year ago | (#44482963)

There are already SSO products out there that constantly change the value of the session cookie.

Re:Sending secrets again (1)

WaffleMonster (969671) | about a year ago | (#44482979)

How about we don't send the same secret every freaking time? Maybe sign the message with the secret, or just trust that the darn TLS session is doing its job?

If any content (not just secrets) in the response can be altered as a result of the request the compression algorithm can be leveraged to leak information about the response.

Re:Sending secrets again (1)

dog77 (1005249) | about a year ago | (#44483355)

My understanding is that the attacker can't alter the secret, but they control the URL of the request, and try to alter so that as the URL more closely matches the secret, the overall request and response compresses to a smaller size. So there is nothing really of value until the attacker gets the secret, since the attacker is the one creating the request (i.e. the URL).

SSL is a weak crypto protocol (0)

Anonymous Coward | about a year ago | (#44482071)

While it is tempting to make-believe SSL provides strong security, this is not the case, never has been. Moreover, nobody seems to believe that it provides strong security: users, UX designers, web developers, browser vendors, third-party vendors, certificate authorities, ⦠certainly none of these.

My personal view is that SSL provides adequate protection against casual passive observer. It would be very useful if we had means of communicating securely on the Internet, but we do not.

Re:SSL is a weak crypto protocol (2)

WaffleMonster (969671) | about a year ago | (#44483031)

My personal view is that SSL provides adequate protection against casual passive observer. It would be very useful if we had means of communicating securely on the Internet, but we do not.

Go ahead and blame the technology for gross misuse and predictable outcome of errecting global trust anchors. SSL is plenty secure when used properly.

Re:SSL is a weak crypto protocol (1)

pnutjam (523990) | about a year ago | (#44487147)

A properly designed VPN provides secure communications.

Why use HTTP Compression? (1)

ebno-10db (1459097) | about a year ago | (#44482077)

FTA: "mitigations include disabling HTTP compression"

What's the point of HTTP compression anyway? Text is a small part of the bandwidth, and most other stuff (pictures, etc.) are already kept/stored/transferred in highly compressed formats like JPEG. Trying to compress files like that does little or no good. What am I missing here?

Re:Why use HTTP Compression? (4, Informative)

mstefanro (1965558) | about a year ago | (#44482129)

Open the Net panel of Firebug on this page and then refresh it a couple of times. Order the HTTP requests by Size. You will see that the HTML of this page is takes the vast majority of bandwidth. Images are simply a "304 Not modified", whereas the HTML is a "200 OK" of ~41KB at this time.
So in case of Slashdot, HTML is the bandwidth bottleneck, not images.

Re:Why use HTTP Compression? (1)

sexconker (1179573) | about a year ago | (#44482157)

Open the Net panel of Firebug on this page and then refresh it a couple of times. Order the HTTP requests by Size. You will see that the HTML of this page is takes the vast majority of bandwidth. Images are simply a "304 Not modified", whereas the HTML is a "200 OK" of ~41KB at this time.
So in case of Slashdot, HTML is the bandwidth bottleneck, not images.

IN the case of Slashdot, there is no bandwidth bottleneck. It's the miles of shitty, shitty, Javascript that make everything turn to shit.
Browse the web without Javascript and with an ad blocker. It's like moving from dialup to broadband.

Re:Why use HTTP Compression? (1)

mstefanro (1965558) | about a year ago | (#44482223)

If 90% of slashdot's traffic is used to send HTML, then that is their bottleneck,
and it's where it is most effective to apply compression (Amdahl's law).

Re:Why use HTTP Compression? (1)

yamum (893083) | about a year ago | (#44484437)

Amdahl's law?

Re:Why use HTTP Compression? (1)

philip.paradis (2580427) | about a year ago | (#44484551)

Amdahl's law [wikipedia.org]

Re:Why use HTTP Compression? (1)

yamum (893083) | about a year ago | (#44484579)

I know this. How is it related to compression?

Re:Why use HTTP Compression? (2)

philip.paradis (2580427) | about a year ago | (#44484669)

I believe you missed the key phrase "where it is most effective." The first sentence of the linked article:

Amdahl's law, also known as Amdahl's argument,[1] is used to find the maximum expected improvement to an overall system when only part of the system is improved.

The reference was to the utility of compression in this case, not the mechanics of it.

Re:Why use HTTP Compression? (1)

yamum (893083) | about a year ago | (#44484685)

mod parent up!

Re:Why use HTTP Compression? (1)

Ash-Fox (726320) | about a year ago | (#44484565)

Amdahl's law?

More information available here: http://bit.ly/196JZ2u [bit.ly]

Re:Why use HTTP Compression? (4, Funny)

Anonymous Coward | about a year ago | (#44482493)

Browse the web without Javascript and with an ad blocker. It's like moving from dialup to broadband.

While I loathe JavaScript on a professional level, I gotta say: It's time to give up the Lynx browser. There can't be that many interesting Gopher sites left!

Re:Why use HTTP Compression? (1)

sexconker (1179573) | about a year ago | (#44488523)

Browse the web without Javascript and with an ad blocker. It's like moving from dialup to broadband.

While I loathe JavaScript on a professional level, I gotta say: It's time to give up the Lynx browser. There can't be that many interesting Gopher sites left!

NoScript is your friend. Allow sane shit, block tracking and advertising horseshit.
Then slap Greasemonkey on there and run your own scripts to replace ugly/shitty scripts.

Re:Why use HTTP Compression? (0)

Anonymous Coward | about a year ago | (#44482271)

thanks! would mod up if I could

Re:Why use HTTP Compression? (2, Interesting)

Anonymous Coward | about a year ago | (#44482167)

You can start to figure out how to render the page as soon as you have the HTML (and javascript, css etc.). It's on the critical path, as the HTML is what tells you what else to download, like images. Any speed-up in transferring the HTML directly leads to lower latency on loading a webpage. Text compresses very well so the reduction is significant. The text is much larger than you think for large pages or even for small pages when you include javascript, css and so on. Even http headers are now being compressed and that on it's own turns out to be worthwhile. This is especially significant on mobile where bandwidth is low, latency is high and every bit transferred costs money (if you are not on an unlimited plan) and drains the battery.

Re:Why use HTTP Compression? (0)

Anonymous Coward | about a year ago | (#44482219)

What you're missing:

1. Large quantities of plaintext compress very well with realtime compression in the webserver. This can actually speed up transfer times of standard web pages/documents, not just "files", by a gargantuan amount. Good MIME types to start compressing by default are text/html, text/plain, and text/xml.

True short story: a client of mine had a programmer located in eastern Europe who was assigned the task of sending the equivalent of an "SQL diff" (for lack of better term, e.g. database X on server X in California, database Y on server Y in Florida, send differences in tables A/B/C between db X and db Y, over to server Y) between two systems. The amount of data was roughly 4GBytes uncompressed if I remember right, but had to be rate-limited due to 95th-percentile concerns. The idiot decided to do the transfer using standard HTTP (with PHP), and did not think to talk to me (server administrator) about it in advance. He begins doing it one night, and I wake up to find our 95th percentile usage dangerously close (as in datacenter/co-lo provider could end up charging us thousands of USD), with the transfer having already taken 2 hours with no idea of how much longer it'd take. I begin reverse-engineering the whole thing from network flows all the way down to the application, which didn't take me long. I then immediately contacted him, asking "Why aren't you using HTTP compression?" "(Your client) didn't tell me to". I explained to him how to do it (roughly 4 lines of code on server and client side). He does the changes, re-initiates the transfer -- the entire thing finishes in about 15 minutes and took up hardly any bandwidth. The client/customer at first insisted something must have gone wrong, "it can't transfer that fast, there's too much delta". The programmer and I both laughed.

2. HTTP is a transfer protocol, it can transfer anything. Think about JavaScript, think about HTML, think about CSS, think about XML with things like SOAP. To assume "everything is already compressed" is a very narrow view. Think a bit more outside the box!

Re: Why use HTTP Compression? (0)

Anonymous Coward | about a year ago | (#44482231)

You may be thinking of static websites. Contemporary dynamic websites contain a lot of JavaScript, CSS, as well as extra HTML markup. Compression trades unimportant cost in CPU usage for a massive decrease of bandwith usage and latency. It is a no-brainer really. If you don't care to think about security, that is.

Re: Why use HTTP Compression? (1)

K. S. Kyosuke (729550) | about a year ago | (#44484837)

If you don't care to think about security, that is.

Why is this such a big deal? Is it a problem to transfer the large static data compressed and then splice the sensitive information into the DOM using JS by making small highly secure HTTPS transfers that avoid compression? Given how the "single-page web applications" are becoming commonplace, this sounds like an obvious idea to me.

Re:Why use HTTP Compression? (1)

Cramer (69040) | about a year ago | (#44482437)

You've not looked at many modern web "applications", have you? The amount of javascript, style sheets, and html markup is ENORMOUS. It's common for sites to save 50-75% of bandwidth enabling compression. (for sites that aren't primarily images, etc.)

Who doesnt throttle/block thousands of requests??? (0)

Anonymous Coward | about a year ago | (#44482363)

I realize most sites have no built in throttling or automatic banning of abusive ip's, but I would imagine most decent (important and so well maintained by someone other than a teenager) sites do. So if this attack requires thousands of attempts, even if the attack attempts are distributed from many ip's, any decent website framework should and could watch for both thousands of request from same ip or thousands of requests for the same base url but different post data... I mean really! There are so many attacks, both dos and breach, that start with malicious, redundant requests - identify and block them!!!! Good Lord folks....

No solution? (0)

Anonymous Coward | about a year ago | (#44482489)

Just disable compression. On Apache its commenting out the LoadModule for mod_deflate. Maybe more of a mitigation than a solution but it should work.

Security 101 (1)

dog77 (1005249) | about a year ago | (#44482715)

It should be security 101 that you never send your secrets, just send proof that you know the secret.

Re:Security 101 (1)

Agent ME (1411269) | about a year ago | (#44482913)

This attack could be used by an attacker to figure out your Facebook username for example. Should Facebook avoid sending your username in pages to you? And then sometimes you actually need to tell the client a secret they have to know, like an anti-CSRF token.

Re:Security 101 (1)

dog77 (1005249) | about a year ago | (#44483165)

For a given https connection, each side can prove to the other that they have knowledge of the authentication cookie, without sending their part of that knowledge. There are probably many ways this could be done, and I am not going to pretend I know the best way, but here is one way. Each side sends random challenges as part of the connection establishment. Each side receives the challenge and encrypts it using the public key generated at the time of the authentication cookie establishment. The challenge response is embedded in the first http request and response. There is some overhead and latency, but next to the TLS/SSL, this is minor, and also reusing connection becomes more important, or other ideas like Google's Quic protocol make even more sense.

Re:Security 101 (1)

gl4ss (559668) | about a year ago | (#44485159)

the access token is in every request going to the direction of the server.. it's the same.

Re:Security 101 (1)

viperidaenz (2515578) | about a year ago | (#44482991)

If the proof you send that you know the secret doesn't change, that proof becomes the secret.

Re:Security 101 (1)

dog77 (1005249) | about a year ago | (#44483181)

No it does not, because you can't use it again. At best you call it a one time secret.

Re:Security 101 (0)

Anonymous Coward | about a year ago | (#44483283)

Easily countered with "Encrypt this random text string for me with our shared secret, and send the response please"

BREACH = CRIME (1)

WaffleMonster (969671) | about a year ago | (#44482923)

Amused by notion one would expect a different outcome with HTTP layer vs TLS layer compression. In every way that matters it is exactly same issue only this time attack analysis is limited to response body.

Also have some trouble with assertion "it is very common to use gzip at the HTTP level." For static assets sure however I expect numbers for dynamic content to be a much different story.

Re:BREACH = CRIME (1)

Covener (32114) | about a year ago | (#44516941)

Also have some trouble with assertion "it is very common to use gzip at the HTTP level." For static assets sure however I expect numbers for dynamic content to be a much different story.

It's in fact very common for dynamic content.

Compress sensitive strings in separate blocks. (2)

complete loony (663508) | about a year ago | (#44483345)

The DEFLATE and gzip formats allows multiple blocks of compressed data as well as blocks containing literals with no compression. Plus, just because the default implementation always looks for duplicate strings, doesn't mean you always have to do so. While it would add a heck of a lot of complexity, it should be possible for a web server to ignore duplicates that occur in sensitive strings, and output them in literal blocks so that they don't effect the frequency data of the rest of the stream. All without requiring any changes to browser implementations. This is far from simple, but could probably be done in a generic way for well known http headers.

Re:Compress sensitive strings in separate blocks. (0)

Anonymous Coward | about a year ago | (#44485111)

Headers are not affected by this attack. CRIME (last year's attack on TLS compression) made them discoverable, BREACH only affects the page source.

Re:Compress sensitive strings in separate blocks. (1)

complete loony (663508) | about a year ago | (#44486255)

CRIME was about TLS and detecting the request. BREACH is about detecting something about the response, that could be in the header, or not.

Re:Compress sensitive strings in separate blocks. (1)

Covener (32114) | about a year ago | (#44516907)

Cannot be in the header, since the headers are not compressed in HTTP.

Re:Compress sensitive strings in separate blocks. (0)

Anonymous Coward | about a year ago | (#44516871)

This is far from simple, but could probably be done in a generic way for well known http headers.

Headers are n/a for this issue, since only the boby is compressed w/ deflate. And it's "nearly impossible" for the server to know which parts of the response are extra sensitive and need to be effectively uncompressed.

Re:Compress sensitive strings in separate blocks. (1)

complete loony (663508) | about a year ago | (#44517293)

I specifically said that this change would be complicated. But it could be done with a set of configurable regular expressions, or new server side language semantics to indicate which strings were sensitive.

Elliptic Curve Cryptography is immune (1)

Anonymous Coward | about a year ago | (#44483439)

Re:Elliptic Curve Cryptography is immune (0)

Anonymous Coward | about a year ago | (#44516887)

ECC is not applicable, ECC and RSA are only used for the assymetric algorithm during the handshake, not to encrypt the body.

Re:Elliptic Curve Cryptography is immune (0)

Anonymous Coward | about a year ago | (#44521029)

What CERT advisory are you talking about? That is a quote from Alex Stamos of Artemis Internet (as it says directly in the article you linked to). The CERT advisory regarding BREACH says nothing about RSA or ECC.

Check your sources. The actual CERT advisory [cert.org] would perhaps be a good place to start.

Random Padding (0)

Anonymous Coward | about a year ago | (#44483553)

Could adding random-length, random padding to the data before compression help?

Re:Random Padding (0)

Anonymous Coward | about a year ago | (#44516901)

Conventional wisdom is that it just requires more requests to see figure out (statistically) if you're colliding with the secret.

Tyranny is a disease in the soul (0)

Anonymous Coward | about a year ago | (#44483575)

This is a known vulnerability to anyone who's thought about it. The solution to this vulnerability is to pad SSL transmissions in a way that totally obfuscates packet size - transmissions from A to B should be quasi-randomly padded so that the transmission size is indistinguishable. The simplest way to accomplish this is by padding all transmissions until they are the same size, which adds a layer of difficulty on top of existing protocols. You can also pad them onto a distribution of expected packet sizes, and deny (or segment and delay) transmissions that exceed that size.

Another parallel vulnerability is that non-dynamic pages on a website can be sniffed out by transmission size. The problem is similar.

We're in trouble (1)

Anonymous Coward | about a year ago | (#44485433)

Anyone else getting the feeling we're approaching security the wrong way? There will never be an end to these kind of exploits. Worse yet, they force us to reduce performance in order to gain security.

Re:We're in trouble (1)

cyrano.mac (916276) | about a year ago | (#44487047)

You're referring to the NSA, I presume?

Re:We're in trouble (1)

OneAhead (1495535) | about a year ago | (#44487423)

So, what's the right way, then?

Re:We're in trouble (1)

Pieroxy (222434) | about a year ago | (#44494941)

Nuke them from orbit. It's the only safe way.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

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

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

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

<ecode>    while(1) { do_something(); } </ecode>