agl

16 ms·

91.
by agl 12y ago
Yes, vs RC4-SHA. There's always five bytes of record header: the record type, u16 length and u16 version. (The version is basically a waste.) For AES-CBC there's an average of 8 bytes of padding (half the block size). For AES-GCM
92.
by agl 12y ago
Details: https://www.imperialviolet.org/2014/02/27/tlssymmetriccrypto...
93.
Easter Hack: Even More Critical Bugs in SSL/TLS Implementations(armoredbarista.blogspot.de)
4 points by agl 12y ago|0 comments
94.
by agl 12y ago
I've not looked at the actual protocol, but it's not impossible. If we assume every packet contains the client's (random, generated at process start) public key then the server could (in theory) perform key-agreement for ever
95.
by agl 12y ago
It's encouraged with NaCl to cache the results of the Diffie-Hellman operation. Thus the protocol can be conceptually stateless, but the cache solves the problem of having to do per-packet, public-key operations. From a quick skim of t
96.
by agl 13y ago
I've submitted code to both. I don't feel that there's a huge difference. (Although NSS has Wan-Teh reviewing, who is a great code reviewer.)
97.
by agl 13y ago
> NSS has more institutional constraints; random people in Germany can't, as a general rule, add support for new TLS extensions to it. Why not? NSS is handled by Mozilla. Mozilla prides itself on being open-source. People can submit
98.
by agl 13y ago
> Suppose you wanted to steal credit cards. The best place to do your MITM would be at the payment processor's connection to the net. In that situation the attacker can pass DV checks as the server and so can get new certificates is
99.
by agl 13y ago
I certainly believe that you're correct to question the utility of revocation. We don't have all CRLs for all CAs (sadly). Some CAs have also asked for the list not to be published so there's no list of the URLs that we do cr
100.
by agl 13y ago
We did this by mistake once and got bug reports about PayPal being flakey. (PayPal was an early HSTS adopter.)
101.
by agl 13y ago
In order to attack an HTTPS connection, the attacker has to have MITM position against the victim: the ability to intercept TCP connections. Such an attacker can obviously also block the CRL/OCSP lookup if one is made. Even with revoca
102.
by agl 13y ago
If Windows XP, it's usually that the root store is corrupt [1]. Otherwise it's usually a bad system clock. If nothing else, see chrome://net-internals and you can repo the problem and find the SSL socket under "Even
103.
by agl 13y ago
The DH fix was just a sanity check and are not sufficient to prevent pre-master secret fixation with DH handshakes. Firefox enforces that the renegotiation certificate chain are valid for the site name which solves the renegotiation issue.
104.
by agl 13y ago
> The downside (to me, not to you) is that the attack has limited impact. I agree, although I think the break of channel bindings is going to turn up some interesting cases that are harder to fix than client-cert auth in browsers.
105.
by agl 13y ago
Why? A 32-bit block counter allows for 256GB messages. As AEAD messages shouldn't be decrypted in a "streaming" fashion (lest one return unauthenticated plaintext), that seems more than sufficient. (We don't have a good
106.
by agl 13y ago
In order to make the AEAD construction suitable for IPSec it looks like the nonce/block counter split needs to be 92/32 rather than 64/64 as I did it.
107.
by agl 13y ago
Chrome uses NSS everywhere except on Android, where it's OpenSSL.
108.
by agl 13y ago
Chrome on Android ships with its own copy of OpenSSL and so can do things different than Android Browser.
109.
by agl 13y ago
For a fuller explanation: https://github.com/agl/critbit/blob/master/critbit.pdf?raw=t... (Note: self promotion.)
110.
by agl 13y ago
Note that we haven't said that pinning found this event. We have several channels by which we receive information about these sorts of things.
111.
by agl 13y ago
For Google properties yes, but not for the majority of sites.
112.
by agl 13y ago
> What is the CA hierarchy "linking back to ANSSI" that chrome is/was trusting? Is the root of that hierarchy still trusted by chrome? Chrome gets the list of root certificates from the underlying operating system. Since A
113.
by agl 13y ago
I believe it was done so that AES-GCM could be implemented in a FIPS module and would not need to depend on the uniqueness of provided nonces. Either that or some standard said that nonces must be unique. (I wasn't around for the discu
114.
by agl 13y ago
Doh! Thanks. I'll ask PR to fix that.
115.
by agl 13y ago
> The secure AES-GCM supports 96-bit nonces That's correct. However, TLS takes four bytes from the handshake key material and uses them as the first four bytes of the nonce. The remaining 8 bytes are all that vary over the lifetime
116.
by agl 13y ago
Preferably the latter.
117.
by agl 13y ago
The feeling seems to be that the analysis of Salsa carries to ChaCha and that ChaCha is slightly preferable: http://www.ietf.org/mail-archive/web/tls/current/msg10222.ht... I started out with Salsa but s
118.
by agl 13y ago
The paper specifies Poly1305-AES, which is a little different. In Poly1305-AES, the point at which the polynomial is evaluated (r) is random, but the value added at the end is calculated as AES_k(nonce). Basically, AES was used to map from
119.
by agl 13y ago
p1mrx is correct - creating plain SHA-1 collisions shouldn't break the CA system. Even though it's believed that one can create an identical-prefix collision with that amount of work, after the MD5 Industries demo all CAs now inje
120.
by agl 13y ago
This class of error is called (by me, at least) a "contoot" because, long ago, when I was writing the JBIG2 compressor for Google Books PDFs, the first example was on the contents page of book. The title, "Contents", was

More ›