Feeds

back to article Unlucky for you: UK crypto-duo 'crack' HTTPS in Lucky 13 attack

Two scientists say they have identified a new weakness in TLS, the encryption system used to safeguard online shopping, banking and privacy. The design flaw, revealed today, could be exploited to snoop on passwords and other sensitive information sent by users to HTTPS websites. Professor Kenny Paterson from the Information …

COMMENTS

This topic is closed for new posts.
Silver badge

If it's timing-based

Would adding a few random uS into the TLS processing be enough to throw the timing detection out?

1
0

Re: If it's timing-based

The easiest mitigation would be wide adoption of the AES counter mode cipher suites. I've always thought that counter mode really ought to be the default for TLS, you make your implementation much faster than CBC.

0
0

Re: If it's timing-based

... "Blocking the attack can be achieved by [...] adding random time delays to CBC-mode decryption"

3
0
Silver badge

Re: If it's timing-based

That was my immediate thought.

1
0
Anonymous Coward

Login cookie for TOR

What's one of them?

I assume it's something to do with the client-to-entry node connection but must say I've never heard of it - can anybody enlighten me?

0
0
Anonymous Coward

Re: Login cookie for TOR

Just looked it up. I can only assume it is referring to cookies within the TOR browser plug-in - but still can't see how that works.

I'm obviously being dumb today.

0
0
Anonymous Coward

Re: Login cookie for TOR

Yeah, there are no "login cookies" in the TOR protocol itself. They could mean login cookies for websites that are being transmitted over TOR, or they could be referring to nonces in the TOR authentication protocol that is used to prevent a corrupt first (entry) node from imitating all the subsequent downstream nodes.

0
0
Childcatcher

Re: Login cookie for TOR

>nonces in the TOR authentication protocol<

Double entendre intentional?

1
0

Re: Login cookie for TOR

Nonce in the protocol? Jim'll fix it!

0
0
Anonymous Coward

Same fix as BEAST?

If I'm reading this correctly, if you've already applied the fix that's being used to mitigate BEAST (switching to RC4 ciphers) it would cover this exploit as well?

0
0

Re: Same fix as BEAST?

Yes. Sort of. RC4 has its own problems as regards security. The cure in this case may be worse than the disease. This attack is for the most part theoretical bullshit in your daily shopping/facebooking/tweeting context since it needs a man-in-the-middle, and a very specific man at that. RC4 may be attacked from anywhere, and not necessarily interactively.

4
0
Holmes

A bit of client-side malware is needed

If you need some client-side malware to exploit this, why would you go to the trouble of decrypting SSL traffic when you could just have your malware capture the information before it is encrypted?

1
0
Bronze badge

Re: A bit of client-side malware is needed

Malware doesn't have to be a .exe file. It could be a JavaScript delivered to a perfectly sandboxed browser via some ad network. Therefore it wouldn't have permission to capture key strokes.

That said, it would seem rather trivial to add a fake random jitter to such responses from the server. This would prevent this attack vector.

5
0
Bronze badge

Re: A bit of client-side malware is needed

I was going to pust just that. It can be flash, javascript, Silverlight, etc...

0
0
Bronze badge
Devil

Nothing is secure, it just has "levels of security". I remember years ago, arguing with a web developer who stated that web pages would never be able to carry a payload to deliver attacks on clients.

Do we now have a new HTTPUS protocol?

8
0
Unhappy

Years ago, your web developer may well have been right... although "never" was obviously a bit of a stretch. I doubt any of us who were there at the beginning would have predicted the chaotic clusterfuck of myriad overlapping, ill conceived and half baked "standards" all those competing proprietors have managed to make of it.

2
0
Bronze badge

>Nothing is secure, it just has "levels of security"

You definitely deserve an upvote for that statement alone. Most fail to understand or fully recognize this.

1
0
Silver badge
Terminator

>>Nothing is secure, it just has "levels of security"

>You definitely deserve an upvote for that statement alone. Most fail to understand or fully recognize this.

Further, Security must be implemented like an onion - in layers. You might be able to peel away one layer, but you hit another layer.

In fact, Security is an Ogre.

SHREK

No! Layers! Onions have layers. Ogres have layers! Onions have layers. You get it? We both have layers.

DONKEY

Oh, you both have layyerrss. Oh. You know, not everybody likes onions. Cake! Everybody loves cakes! Cakes have layers.

Remember folks - build security in layyerrss! And have some cake.

1
0
Terminator

Also, remember that you can’t hide secrets from the future with cryptograph.

0
0

...

No, we predicted it alright. Question is, how do you stop a train crash while its happening?

0
0
Silver badge

Not really levels, either

Even "levels of security" is misleading - it suggests a single dimension, ranging from completely insecure to greater and greater security (with "secure" as an asymptotic limit).

Security is really a matter of threat classes and their associated costs to the attacker. You pick the threats you're most concerned with (based on your threat model) and implement measures that increase the work factor and other costs until the attacker is better off choosing a different class of attack, or better yet a different target. So it's a graph, not just a line, and your goal is to eliminate the cheap paths from the root to anything an attacker might want.

An attack like Lucky 13 has too high a cost (have to mount a MITM attack, gather a lot of side-channel data, etc) for an attacker to just use it against random targets in the hope of landing something of relatively minor value. As with most attacks against SSL/TLS, the attacker's better option is to find vulnerable web sites with rewarding data (eg credit-card information).

0
0

If memory serves me right, i've read about an ancient exploit that cracked passwords by timing how long it took the OS to reject them (they had to be checking char by char and rejecting at first bad).

One would think guys working on such up and above stuff like heavy crypto would consider reasonably measurable right/wrong response time as an attack vector...

Or maybe they thought faster message processing for BoastingRightsTM was more important than adding artificial jitter to make it safer...

1
0

This post has been deleted by its author

There was an OS that would inform the app that it just caused a page fault. It's password-checking mechanism was strcmp() against the unhashed recorded one.

A program could place the first character of a trail password in the last byte of memory, wait for the next page to be swapped out. Then it called checkpassword(). If a no page fault occurred, then the first character was incorrect, and another one was tried. If a fault was caused, then the first character of the password was correct;, and the second letter was attempted.

Thus, cracking a 8 character password went from 96^8 to 96*8 tries.

Oops.

2
1
Silver badge

There's a huge amount of literature on side-channel attacks, including timing, power consumption, etc. There are a lot of side channels that need to be blinded (often by whitening, ie adding noise). It's not easy for crypto designers to catch all of them.

I think the OS you're thinking of is TENEX.

0
0
Gold badge
Unhappy

Note the fail is in the *protocol* not implementations.

I'd sort of figured that by now the people who develop protocols (especially security related ones) would have some kind of IDK "regression test" of attacks that have accumulated over the decades that such protocols have been being built.

A sort of archive of stuff that breaks features and the conditions under which the crack works (and when t fails)

Apparently not.

0
0
Anonymous Coward

Use BT Internet...

...then random packet loss and timing errors in using the internet will be introduced by BT to such an extent as to make any packet analysis for encryption meaningless.

/trying to get my home hub to server wireless home networking without needing a reboot every 30 mins

//looking at BT packet shaping and contention ratio and thinking packet speed consistency is the least of their worries

2
1

"...use <insert variable service ISP here>..."

I was wondering how good your ISP has to be for this exploit to work.

If they need to measure microsecond level timing differences, is the information superhighway (sorry, temporary 90s Clive James flashback...) really consistent and quick enough for most people to carry this out?

0
0
Paris Hilton

Wow...a perk of being with BT!

0
0

It's about time they made this sort of 'research' illegal

Maybe I'll pop around to their house, throw a brick through the window and then tell them I was demonstrating their security problem.

0
3
WTF?

Re: It's about time they made this sort of 'research' illegal

Would you rather just ignore the possibility of security issues?

0
0
Silver badge

Re: It's about time they made this sort of 'research' illegal

Trolling or stupid? It's so hard to tell.

0
0
Bronze badge

Perfect conditions

From what I see, this attack requires perfect conditions:

1 client accessing a single server, no other clients connecting to said server

*If the server is busy with another client, then the packet will be delayed and change the timing.

An unencumbered router, or at least one that is perfectly consistent in moving packets

*Any slight delay could change this packet timing, even a simple CRC check would take a different length of time on different packets.

*Special features on the router may also delay the packet randomly

No specialized network equipment

*Load Balancers, firewalls or NAT/PAT device would add random delays due to processing, of course a pair of load-balanced servers would have different timing even they used machine with only one-off serial numbers.

All links are the same exact length

*If the packet is going over a set of bonded links (Like nearly all ISPs have and most companies), a difference in cable length would delay the packet enough to defeat this attack

Using a non time-division style network

*crossing ISPs wouldn't work or even within the same ISP. Cellular and 3/4G networks wouldn't work either.

While this is good work and patches should be made for the affected products, an attack isn't practical outside of a lab.

1
0
Silver badge

Re: Perfect conditions

From what I see, this attack requires perfect conditions

Sigh. That's the first critique that's always leveled against side-channel attacks. Then someone goes and demonstrates how to increase the probability those conditions will hold, until they make the attack practical.

Seriously, people - did it ever occur to you that security professionals might have thought of this stuff before Joe Average Reg Commentator?

While this is good work and patches should be made for the affected products, an attack isn't practical outside of a lab.

That's what people said about the attacks on Netscape's original PRNG. They were wrong.

0
0
This topic is closed for new posts.