from the security-is-difficult,-but-not-that-difficult dept.
Submitted via IRC for TheMightyBuzzard
A group of researchers has discovered 184 HTTPS servers that are wide open to attackers looking to inject seemingly valid content into encrypted sessions. Some of these servers belong to the credit card company VISA, the Polish banking association ZBP, and the German stock exchange.
They are vulnerable to these attacks because they used a duplicate cryptographic nonce with the AES-GCM cipher during the TLS handshake between the browser and the HTTPS-protected sites. This means attackers that are able to monitor the connection could reconstruct the authentication key and misuse it to, let's say, inject malicious code in the site or bogus forms to harvest user data.
The user, i.e. the browser, would have no way of noticing the attack.
[...]
The researchers have also found over 70,000 HTTPS servers using random nonces, which theoretically puts them in danger of nonce reuse attacks. Such an attack would be much more difficult to pull off – but not impossible.
(Score: 0) by Anonymous Coward on Sunday May 29 2016, @04:26AM
Maybe I'm dense, but what kind of nonce are you supposed to use? Based on my RTFA, static nonces are bad because they can be duplicated, random nonces are bad because they can be duplicated/predicted and counters are bad because they can be predicted. This leaves me wondering what kind of nonce is left/secure. Plus, my reading of Wikipedia is that they are random by definition, so why would TFA say they are bad? Contradictory advice like this is why people hate cryptography/security and just say "fuck it, give me something measurable, like speed."
(Score: 3, Informative) by Scruffy Beard 2 on Sunday May 29 2016, @05:00AM
I think it was a bad summary.
The random nonce is better that re-using the same nonce over and over again. However, if you don't change your encryption key periodically (every 4 TB or so), you are vulnerable to nonce re-use. The found 184 servers giving everybody the same nonce, and 70,000 servers using a random nonce.
Enabling Perfect Forward Secrecy can likely mitigate the problem
(Score: 0) by Anonymous Coward on Sunday May 29 2016, @05:08AM
From the paper linked by TFA:
3.3 Random nonces
A less clear risk is present if an implementor chooses to use random values
as a nonce. If only a few TLS records are encrypted with the same key,
then a random nonce does not pose a risk. However, if a large number
of records is encrypted with the same key, the risk may become relevant.
If choosing nonces at random after 2**28 encryptions the probability of a
nonce collision will be around 0,2 % due to the birthday paradox. After
2**33 collisions the probability will be more than 80 % (see Figure 3.3).
The size of a TLS record is determined by many factors, therefore it
is not trivial to calculate the exact amount of data necessary to generate
a nonce duplication with an implementation with random nonces. It is
however most likely in the area of Terabytes. There are probably few
scenarios in which this is a problem. VPN networks may use the same
connection for such a large number of TLS records.
In other words, any time you have duplicate nonces within the same TLS session, there is a theoretical opportunity for an attacker to recover the authentication key. That would obviously be the case if the same nonce is (stupidly) used every time. Best practice seems to be chosing the first nonce at random, then incrementing it to generate successive nonces, because that guarantees no duplicates within the lifetime of the universe (using a 2**64 nonce space). But what happens if a *each* nonce is selected "at random"? That would seem to me to be dependent on the specifics of the randomization process, and the number of unique values in the RNG space. Not saying the researchers are wrong, but their explanation doesn't seem to be sufficient.
(Score: 0) by Anonymous Coward on Sunday May 29 2016, @02:12PM
I wonder if the first nonce really needs to be random. Can't you just take the current (UNIX) timestamp as nonce? This will increase over time, every time. I always thought that the nonce is to prevent to brute force the private key, when the data itself is somewhat predictable (as a salt in a password hash).
Someone can explain why this is different?
(Score: 3, Informative) by bitstream on Sunday May 29 2016, @10:20AM
The server needs to create a nonce that is random for every occasion and regenerate it when the amount of data reaches circa 1 terrabyte.
A lot of them instead gives out static nonce, counter based ones, or generate a properly random one but then don't regenerate it.
(Score: 0) by Anonymous Coward on Sunday May 29 2016, @06:52AM
Two times now I have tried to pay by card online but stopped when it asked for my date of birth. I don't care who or how VISA or the merchant was hacked. I only care that they tried and got to the point of data harvesting.
Here is how it should work: Open store website ; select item to buy; go to checkout; accept; put in credit card details; wait for confirmation; store sends item to you during next business day.
What happened was that after the credit card details are entered and accepted it says "We need to verify who you are" then puts another form up with fields for entering personal information. Date of birth. Drivers licence. Data you would never enter online to buy from a store.
This article doesn't shock me. I rang visa about the extra form that popped up. The call center guy said not to worry about it. That it was probably just the website gathering more information.
Perhaps it is time for a global currency to take over. One that does not involve visa or mastercard. Go bitcoin?
(Score: 2) by urza9814 on Thursday June 02 2016, @08:52PM
Sounds like it might have been the "Verified by Visa" program?
https://usa.visa.com/pay-with-visa/featured-technologies/verified-by-visa.html [visa.com]
Comes up sometimes when I'm shopping at Newegg, but as far as I can tell it's completely optional -- usually it pops up after you've completed the rest of the order, and you can just close the window and your order will go through just fine. Or sometimes there's a cancel/skip button you can use.