No, this attack is a TIMING attack which relies on the different amount of time it takes to check the two different cases.
The whole point of the timing attack is to distinguish block errors from MAC errors. If the stack already tells you (through different alert codes) which one of those happened, you don't have to bother with a timing attack. Read RFC 2246 p. 26.
Amen. Use SEAL if you need stream ciphers. It doesn't have any issues like RC4 does regarding intellectual property.
Seal is patented by IBM (p. 400 of Applied Cryptography) while RC4 is not patented at all (despite its sketchy past as a "trade secret"). Also, there are no SSL ciphersuites defined for SEAL, so you wouldn't interoperate with anyone.
So using SEAL wouldn't actually be useful and it is even more constrained with respect to intellectual property than RC4 is.
The protocol RFC says that you should send different alert codes on the wire for the two different cases which is what this attack needs to work.
So the protocol is flawed in the sense that following the RFC to the T makes you vulnerable.
However, it is not an unfixable problem (implementations can avoid the attack if they so choose) and it is certainly not as dire as the BBC article would make it out to be.
It's a slight bug in the SSL protocol that is entirely fixeable in the implementation.
The bug in the protocol is that the RFC says that for block cipher decryption errors, you should report a "decryption failed" alert but for MAC errors you should report a "MAC error" alert. This opens you up to attacks.
A good implementation will report "MAC error" in both cases, and take the same amount of time to do that reporting in both cases (this is what OpenSSL's fix does). This doesn't follow the RFC but it shuts down this avenue of attack.
So OpenSSL is safe and the Heise was overstating things in a very misleading way.
The easiest way to avoid this flaw (which unfortunately few people know because of all of the poorly written hype) is to use RC4.
The flaw is only present when using block ciphers, and RC4 is a stream cipher.
This measure can be taken on the client side by setting your browser's SSL preferences.
All good SSL-enabled browsers (Mozilla, Opera, etc.; basically anything except IE) will let you disable non-RC4 ciphers for SSL. Turn off RC2, DES, 3DES, and AES. Only leave RC4 suites (or C4 suites as they are called in Opera).
This measure can be taken on the server side by configuring your web server's SSL configuration to only support RC4 cipher suites (RC4 is the only stream cipher defined in SSL).
If you are using OpenSSL, they made a new release (0.9.6i and 0.9.7a) yesterday that prevents this attack from working. Basically, they made the new code take identical amounts of time for the block decryption failure vs. the MAC failure which thwarts the timing attack described by LASEC. Even their old code has been smart enough to report the same error on the wire, but the old code had a timing difference (block error would skip the MAC computation).
This is not the end of the world. This is not an insurmountable flaw in the SSL protocol (although they really shouldn't have specified block decryption error as one of the alert types in the first place).
Just use RC4 for now and upgrade your web servers when you can.
RC4 is still considered a trade secret. It was reverse engineered in an anonymous Usenet posting. It was certainly not provided in source form by Rivest.
OpenBSD is released (not surprisingly) under the
BSD license. The source for strlcpy/strlcat is easily attainable. You're free to bundle the implementations of those two functions in your problem under the terms of that license. It's not too difficult considering how lenient that license is (even if your product is commercial).
You needn't limit yourself to the standard C library. After all, that is the library that brought you gets() and strcpy().
99% of people using strncpy don't actually bother
to read the definition of what it actually does.
Hint, this code is buggy:
char buf[1024];
strncpy(buf, big_ass_string, sizeof buf);
strncpy doesn't bother adding a null-terminator
in the case where big_ass_string is too big.
Most people don't realize that they have to
do all of this to be safe with strncpy:
strncpy(buf, big_ass_string, sizeof buf - 1);
buf[sizeof buf - 1] = '\0';
The real solution is to use a function that
doesn't have such crappy behavior: strlcpy
strlcpy(buf, big_ass_string, sizeof buf);
It always does null-termination. You never
have to lie to it about the size of your string.
Same goes for strncat (bad) and strlcat (good).
Thank the OpenBSD developers for these.
They are very useful in avoiding overflows when
you don't have the option of using C++ and
the string class.
Yes, they are slow at implementing SMP because
they don't care about SMP relative to other things.
However, the crack about ipv6 is stupid. OpenBSD
has had a working ipv6 stack for a long time
(they were first OS to ship with an IPsec stack
at all). Get your facts straight.
It is legitimate P2P where the bands actually want to be listed and have their live shows distributed for free. If your band is not listed, contact them, and they will add your band.
You're in better company there (think Fugazi, not Bon Jovi).
It it really reasonable to - in order to improve the efficiency of a system - introduce ineficiency into that system and and expect a positive outcome?
Yes, because the current system is more dangerous.
Requiring
the solution to a computationally intensive
puzzle is a common technique
in denial-of-service prevention,
especially in protocols where the amount of
computation is already lopsided.
For example, SSL servers are an easily DOSable
target because the server does lots more work
(RSA decryption) during a handshake than
a malicious client does. One solution to this
problem is a protocol modification that requires
the client to answer a "puzzle" of the server's
choosing. This is no problem for a legitimate
client making a few connections, but it keeps
out the guy trying to DOS the server with thousands of connections.
It's the same thing with spam. It's too easy
for a spammer to make mail servers pass around
huge spams to thousands of people on their behalf. But if the mail server required the
spammer to answer a "puzzle" (hashcash) for
each copy of the message sent, that would
make the spammer's life much harder without
making the legitimate mail sender's life that
hard.
Think about mistyping your password at the
telnet prompt. Telnet intentionally waits
for a few seconds before letting you retry
to make it harder to brute force. It doesn't
kill you to wait a few seconds, does it?
It's the same concept.
You are right though that it has to be adopted
on a widespread basis or the spammer just goes
to the relay that doesn't use hashcash.
Microsoft officials said it makes sense for the operating system to provide cryptographic services to any application that needs it, instead of each application having to include its own cryptographic technology.
This "makes sense" up until the point where you
have to patch your kernel instead of upgrading
a library. When OpenSSL had a bug, they fixed
it and you could upgrade OpenSSL. When Konqueror
had this specific bug, it could be uprgraded
easily enough. Now Windows users have to
patch their entire OS to fix this (or just
use another browser that doesn't use the
crypto-in-the-kernel routines).
You have to connect to the central database for EVERYTHING. All files are locked until you manually checkout a file. If you have a slow network connection or disconnect periodically, you have to reconnect every time you want to make a change (add a file, edit a file, change attributes on a file, see what files have changed, etc).
Actually, if you use CVS properly,
you still have to
contact the server for all of these things:
cvs diff
cvs commit
cvs co
cvs update
cvs edit
Technically, you can edit without cvs edit,
but it's less "polite".
So there isn't really a big win of CVS over
Perforce regarding how connected you have to be.
I know: since the bug affected so many people, Theo thought it would be better to bury the problem in his privsep code, instead of fixing it and letting the blackhats run "diff" and find it for an easy 0-day-'sploit. In other words, security by obscurity, just like the big guys. That stinks, if you ask me.
This was not "security by obscurity". They just
waited a few days before releasing the details.
When MS gets notified of a bug, they sit on their
ass for a month before releasing a patch that doesn't work. In the meantime, they say nothing.
The OpenSSH team got the fix in in less than a week, and gave you enough information to
cover your ass in the meantime. I think the
whining here about this episode is way out
of hand considering the OpenSSH team's
very quick handling of this bug and past bugs.
Her having access to the details of Clipper
hardly makes her some unbiased expert on the
technical merits of that chip.
Do you recall when the FBI went shopping for
universities that would sign of on Carnivore
saying that it was great and that it wouldn't
harm anyone's privacy?
Some universities (MIT) refused to sell out
and sign there name to the FBI's pre-written
statement about what the "university review"
had found, so the FBI had to go to universities
with less scruples that would sign off on
such things.
The point is that the FBI lobbied Clipper in
the same way. I'm sure they knew she would
say this kind of stuff before they even
approached her with any of the actual details.
Also, for what it is worth, Clipper was
completely bunk. Key escrow is a bogus concept
anyway, but that aside, Clipper wasn't even
a technically sound implementation of key escrow.
They used a hash function so weak that you
could erase your chips serial number, rewrite
it as something random, and then collide
their crappy hash to make it impossible to tell
that you had tampered with the serial number.
Voila, a Clipper for which they wouldn't
know the key.
No, it isn't. Egress filtering is making sure that
IP address with forged source addresses never
make it out of a given network. It has nothing
to do with reading email. Egress filtering
makes stuff like DDoS much easier to track
down, since you wouldn't have to deal with
spoofed IP source addresses.
I wonder if he's had the opportunity to tackle Dan J. Bernstein [cr.yp.to] yet. Although his terms seem to meet the Free Software criteria for me, I hear all the time that Qmail isn't free software.
The OpenBSD team ran into this with that guy's software. They yanked it from the distribution. The issue was that for uniformity reasons, the OpenBSD people wanted the installation to point to a certain directory which was different from where DJB's thing tried to install itself. His
license doesn't allow for something this trivial,
the OpenBSD team didn't feel like having to ask
this guys permissions about stuff like this, and so it was yanked from their ports tree (I think).
Wrong again. Phish is on Elektra (RIAA). The Dead
recorded on Warner Brothers for most of their
early career (American Beauty, Live Dead, etc.)
I like the Dead, and its free to trade
their shows non-commercially, but their early
albums are indeed controlled by the cartel
otherwise known as the RIAA. I believe the
later releases are not RIAA controlled (the
stuff like Dick's Picks that you buy straight
from them).
Slashdot Mirror
The whole point of the timing attack is to distinguish block errors from MAC errors. If the stack already tells you (through different alert codes) which one of those happened, you don't have to bother with a timing attack. Read RFC 2246 p. 26.
Seal is patented by IBM (p. 400 of Applied Cryptography) while RC4 is not patented at all (despite its sketchy past as a "trade secret"). Also, there are no SSL ciphersuites defined for SEAL, so you wouldn't interoperate with anyone.
So using SEAL wouldn't actually be useful and it is even more constrained with respect to intellectual property than RC4 is.
You should upgrade your OpenSSL version to 0.9.6i or 0.9.7a. If that is not possible, disable all non-RC4 ciphersuites in the mod_ssl config.
This flaw is specific to the SSL protocol. OpenSSH only uses OpenSSL's crypto library, not its SSL stack. (Open)SSH should not be affected.
However, it is not an unfixable problem (implementations can avoid the attack if they so choose) and it is certainly not as dire as the BBC article would make it out to be.
The bug in the protocol is that the RFC says that for block cipher decryption errors, you should report a "decryption failed" alert but for MAC errors you should report a "MAC error" alert. This opens you up to attacks.
A good implementation will report "MAC error" in both cases, and take the same amount of time to do that reporting in both cases (this is what OpenSSL's fix does). This doesn't follow the RFC but it shuts down this avenue of attack.
So OpenSSL is safe and the Heise was overstating things in a very misleading way.
This measure can be taken on the client side by setting your browser's SSL preferences. All good SSL-enabled browsers (Mozilla, Opera, etc.; basically anything except IE) will let you disable non-RC4 ciphers for SSL. Turn off RC2, DES, 3DES, and AES. Only leave RC4 suites (or C4 suites as they are called in Opera).
This measure can be taken on the server side by configuring your web server's SSL configuration to only support RC4 cipher suites (RC4 is the only stream cipher defined in SSL).
If you are using OpenSSL, they made a new release (0.9.6i and 0.9.7a) yesterday that prevents this attack from working. Basically, they made the new code take identical amounts of time for the block decryption failure vs. the MAC failure which thwarts the timing attack described by LASEC. Even their old code has been smart enough to report the same error on the wire, but the old code had a timing difference (block error would skip the MAC computation).
This is not the end of the world. This is not an insurmountable flaw in the SSL protocol (although they really shouldn't have specified block decryption error as one of the alert types in the first place).
Just use RC4 for now and upgrade your web servers when you can.
RC4 is still considered a trade secret. It was reverse engineered in an anonymous Usenet posting. It was certainly not provided in source form by Rivest.
You needn't limit yourself to the standard C library. After all, that is the library that brought you gets() and strcpy().
Hint, this code is buggy:
char buf[1024];
strncpy(buf, big_ass_string, sizeof buf);
strncpy doesn't bother adding a null-terminator in the case where big_ass_string is too big. Most people don't realize that they have to do all of this to be safe with strncpy:
strncpy(buf, big_ass_string, sizeof buf - 1);
buf[sizeof buf - 1] = '\0';
The real solution is to use a function that doesn't have such crappy behavior: strlcpy
strlcpy(buf, big_ass_string, sizeof buf);
It always does null-termination. You never have to lie to it about the size of your string. Same goes for strncat (bad) and strlcat (good). Thank the OpenBSD developers for these. They are very useful in avoiding overflows when you don't have the option of using C++ and the string class.
However, the crack about ipv6 is stupid. OpenBSD has had a working ipv6 stack for a long time (they were first OS to ship with an IPsec stack at all). Get your facts straight.
Try distributing your music on Furthur, not Kazaa
It is legitimate P2P where the bands
actually want to be listed and have their
live shows distributed for free. If your band
is not listed, contact them, and they will add
your band.
You're in better company there (think
Fugazi, not Bon Jovi).
http://www.furthurnet.org
Check out http://www.furthurnet.org.
Legitimate P2P sharing of live music.
A new release will be out within a month that contains many stability-related improvements.
Yes, because the current system is more dangerous.
Requiring the solution to a computationally intensive puzzle is a common technique in denial-of-service prevention, especially in protocols where the amount of computation is already lopsided.
For example, SSL servers are an easily DOSable target because the server does lots more work (RSA decryption) during a handshake than a malicious client does. One solution to this problem is a protocol modification that requires the client to answer a "puzzle" of the server's choosing. This is no problem for a legitimate client making a few connections, but it keeps out the guy trying to DOS the server with thousands of connections.
It's the same thing with spam. It's too easy for a spammer to make mail servers pass around huge spams to thousands of people on their behalf. But if the mail server required the spammer to answer a "puzzle" (hashcash) for each copy of the message sent, that would make the spammer's life much harder without making the legitimate mail sender's life that hard.
Think about mistyping your password at the telnet prompt. Telnet intentionally waits for a few seconds before letting you retry to make it harder to brute force. It doesn't kill you to wait a few seconds, does it? It's the same concept.
You are right though that it has to be adopted on a widespread basis or the spammer just goes to the relay that doesn't use hashcash.
This "makes sense" up until the point where you have to patch your kernel instead of upgrading a library. When OpenSSL had a bug, they fixed it and you could upgrade OpenSSL. When Konqueror had this specific bug, it could be uprgraded easily enough. Now Windows users have to patch their entire OS to fix this (or just use another browser that doesn't use the crypto-in-the-kernel routines).
Actually, if you use CVS properly, you still have to contact the server for all of these things:
- cvs diff
- cvs commit
- cvs co
- cvs update
- cvs edit
Technically, you can edit without cvs edit, but it's less "polite".So there isn't really a big win of CVS over Perforce regarding how connected you have to be.
This was not "security by obscurity". They just waited a few days before releasing the details. When MS gets notified of a bug, they sit on their ass for a month before releasing a patch that doesn't work. In the meantime, they say nothing.
The OpenSSH team got the fix in in less than a week, and gave you enough information to cover your ass in the meantime. I think the whining here about this episode is way out of hand considering the OpenSSH team's very quick handling of this bug and past bugs.
The point is that the FBI lobbied Clipper in the same way. I'm sure they knew she would say this kind of stuff before they even approached her with any of the actual details.
Also, for what it is worth, Clipper was completely bunk. Key escrow is a bogus concept anyway, but that aside, Clipper wasn't even a technically sound implementation of key escrow. They used a hash function so weak that you could erase your chips serial number, rewrite it as something random, and then collide their crappy hash to make it impossible to tell that you had tampered with the serial number. Voila, a Clipper for which they wouldn't know the key.
It is http://furthurnet.com Sorry.
Check out http://furthuernet.com.
A GPLed Java program with absolutely no bullshit
spyware. It is for sharing legally tradable
live performances of bands that allow such things.
Higher level protocols can leak NAT information.
HTTP and FTP do this just to name a few.
FTP clients will embed their IP in the PORT command.
Stupid HTTP clients (IE) will give up their
IP in cookies or in HTTP headers.
Both of these can make it out of a NAT.
No, it isn't. Egress filtering is making sure that IP address with forged source addresses never make it out of a given network. It has nothing to do with reading email. Egress filtering makes stuff like DDoS much easier to track down, since you wouldn't have to deal with spoofed IP source addresses.
The OpenBSD team ran into this with that guy's software. They yanked it from the distribution. The issue was that for uniformity reasons, the OpenBSD people wanted the installation to point to a certain directory which was different from where DJB's thing tried to install itself. His license doesn't allow for something this trivial, the OpenBSD team didn't feel like having to ask this guys permissions about stuff like this, and so it was yanked from their ports tree (I think).
I like the Dead, and its free to trade their shows non-commercially, but their early albums are indeed controlled by the cartel otherwise known as the RIAA. I believe the later releases are not RIAA controlled (the stuff like Dick's Picks that you buy straight from them).