> The vulnerability here is tricky to exploit but actually simple to describe.
Yessss finally
> There's a padding oracle
hysterical sobbing sounds
Yessss finally
> There's a padding oracle
hysterical sobbing sounds
Padding oracles are a subset of "error oracles", which are oracles that come from exception processing. The "useful computation" you're being forced into doing is "decrypting, checking for errors, and then somehow signaling the error."
Think of error oracles this way: imagine a situation in which an adversary can hand you a ciphertext which, when decrypted, will trigger an error (in a padding oracle, that error is "the padding is wrong"). Now imagine that the error, revealed to the adversary, allows them to infer one bit of the plaintext. Not very useful by itself, but, as a final step, imagine that the attacker can permute the same ciphertext, generating (or not generating) an error and allowing them to reveal a different bit of the plaintext.
As long as they can keep doing that, they'll eventually recover the whole plaintext.
Here's a good starting point:
I think the point GP was making was that he got literally 4 words into the "simple to explain" explanation before realizing this explanation is going to be like tons of other things he reads here and elsewhere that require so much prior and specialized knowledge as to be nearly impossible for someone lacking a high level of experience in the area to understand.
I often feel this way when security topics come up on HN. I've been writing code a long time and I think I'm of moderate intelligence and I often have no idea what anyone is talking about. I try not to lose sleep over it because I understand that security can be really, really complicated (even if the issue is "easy to explain") and so I'm just not going to get it.
So it's not very important that you understand exactly how to go from "errors/exceptions generated by the target" to "recovery of plaintext". Even if you understand the specifics of those kinds of attacks, they're even more complicated (and fun) here.
The interesting nut of the attack is: there's a well-known error oracle in both TLS and SSLv2, but it's long since been mitigated in both protocols. However, details of the crappy crypto in SSLv2 conspire to make the mitigation for padding oracles in SSLv2 ineffective, and you can use the SSLv2 oracle to attack TLS ciphertexts if TLS and SSLv2 ever share keys.
I think everyone can understand why "Error: The fourth character of your password is wrong" is both more "usable" and insecure.
Had to deal with a program recently that gave "corrupted MAC" error on the server. All searching etc hinted at it being a network issue. Only after having fiddled with the network for ages and getting nowhere did i set up a loopback test and found the same error.
Turns out the program i was dealing with was using an old lib.
It's setup so that you can only see the very last letter in what you think is a really long sentence someone has typed into a text editor.
With your bluetooth keyboard you move to the beginning of the line and repeatedly hit the spacebar, taking note each time what the new letter is that you can see through the keyhole.
We had user search functionality for an internal business application. We allowed searching by several fields, such as name, and phone number, and allowed partial matches, where the first part of a field matched.
Phone numbers were restricted information for some users, and we didn't display them in the search results. But you could search by those fields, if you already knew the value.
It turned out we left 'partial matching' available in the phone number field.
If you knew the name of a particular person, you could do the following:
Enter their name to confirm a single match shows up.
Then enter the same search, but put a single digit in the phone field, say "0". If no result came back, you knew that their phone number didn't start with that digit. So you try the next, 1, 2, 3... when you hit, say 5, you get a result. Now you know their phone number starts with a 5.
So you start on the next digit. 50-, 51-, 52-... and you get the next digit. Eventually you can reveal their entire phone number, and it was fast enough to do manually.
It wasn't super critical for the internal system, so we changed the phone numbers to exact match only and that was fine. but let's continue.
Let's say we had a REALLY slow system, and it checked each digit one at a time, taking one second per digit, and sent back a failure when it hit a non matching digit. We aren't leaking information DIRECTLY, you get no records back for partial matches. But we ARE leaking information indirectly. The attack now works roughly like this:
Do the same verification search to get a record.
Now do the same digit by digit search, start with 0. Carefully time the delay when you submit the question, and when the error shows up. If it's almost instant, you know the first digit failed. If it takes about a second to give you an error, you know the first digit worked.
You then continue to the second digit. One second fails, two seconds verifies.
Using only the timing you can determine each digit, and reveal the entire number. This is not the main information channel, the timings are what they call a side channel. The service that gives you this information by responding with an error and varying the time is an 'oracle' because it answers your questions.
This seems clear at a one-second time scale and obvious when it's explained, but it turns out that even over public networks with enough tries you can determine very small time differences, on the millisecond or less scale.
It turns out there are a lot of variations on this, some of them are very complex, and secure systems need to work very hard to run in the same amount of time ("constant time") for any query to avoid leaking information this way. The timing exploit described above is a very simplified form of the root of the described vulnerability.
This situation helped me understand 'timing attacks' and 'oracles' in a more mundane coding context, and hopefully it will help others.