agl

17 ms·

121.
by agl 13y ago
The slide deck has an impressive list of authors, but slide 55 (about TLS and ECC) appears to be misleading without the context of the talk itself. I didn't see the talk, so I don't know what they were aiming at, but ECC works the
122.
by agl 13y ago
It's certainly possible: https://www.imperialviolet.org/2012/09/21/crime.html
123.
by agl 13y ago
Orin Kerr (law professor at George Washington University) has written on the subject of whether the collection of phone metadata violates the 4th Amendment, given the history of Supreme Court opinions on the matter: http://www.vo
124.
by agl 13y ago
Good to know. I knew that I needed to do it, but I'll be sure to add support for this prior to Go 1.2. (The TLS stack doesn't support renegotiation at all, so it's not vulnerable, but a client can't know that unless it e
125.
by agl 13y ago
That section is dealing purely with an attacker who wants to impersonate a ChannelID. It's correct that an attacker cannot fool the real server into believing that it is in possession of a ChannelID, even if the attacker has the server
126.
by agl 13y ago
I'm afraid that the general AES implementation in Go is not constant-time. If you have a machine with AESNI instructions then they will be used and they are constant time. AES is terribly hard to implement in a performant and constant-time
127.
by agl 14y ago
CBC at the moment I think. There's still the possibility of clients without record splitting, there's timing issues in AES itself, there's lots of possibilities for bad server padding implementations. I have TLS 1.2 and AES-GCM working in N
128.
by agl 14y ago
> First, the record split problems caused compat issues. It did, but I think we're through it now. IE, Firefox and Chrome have all had it on for a while.
129.
by agl 14y ago
I'm not sure, but in the back of my mind I don't think that it does. I've agreed to write about this stuff for the Web PKI Working Group so I'll need to do a survey of the various capabilities at some point.
130.
by agl 14y ago
It's a question of terminology, but when groups like Chrome Security, Mozilla etc talk about MITM certificates and that they are forbidden, we mean those that are used for intercepting traffic.
131.
by agl 14y ago
(Copying this reply of mine from another part of the thread as you're not the only person to ask.) Name Constraints support is pretty good in modern certificate libraries. It's certainly in CryptoAPI these days which accounts for the bulk o
132.
by agl 14y ago
Name Constraints support is pretty good in modern certificate libraries. It's certainly in CryptoAPI these days which accounts for the bulk of users. But there are two ways to use Name Constraints: they can be marked critical or non-critica
133.
by agl 14y ago
"MITM certificates" are those used for the purpose of intercepting secure traffic. Many organisations have the certificates to do that, but are under audits, and technical and legal constraints not to. That's very different from, say, Trust
134.
by agl 14y ago
They aren't MITM certificates, they are cross-signs for enterprise deployments. If you run a large enterprise you might have lots of foo.corp.example.com and bar.corp.example.com hosts. A cross-sign would allow you to issue certs for these
135.
by agl 14y ago
Scheduling jitter on a loaded server is going to make this attack much harder for sure. If you have a sufficiently good position against the server, you can just delay all other traffic going into it but, except for that, such jitter may we
136.
by agl 14y ago
Against DTLS it appears to practical, both because the connection isn't destroyed and because the difference can be amplified by the researcher's Heartbeat trick from http://www.isg.rhul.ac.uk/~kp/dtls.pdf . Against TLS it's tougher. The p
137.
by agl 14y ago
Both AES and GHASH have their own timing side-channel issues. If you need to encrypt something, I recommend NaCl: http://nacl.cr.yp.to/
138.
by agl 14y ago
TLS does CBC wrong: it authenticates the plaintext and then encrypts the plaintext and MAC. Since CBC mode needs to pad its input, this means that the padding is outside of the authentication. So, when decrypting, the padding has to be remo
139.
by agl 14y ago
The attacker lets the handshake complete normally and then intercepts the transmission of the encrypted record that contains the secret that they wish to decrypt. (Assuming that the parties negotiated a CBC ciphersuite.) The attacker can th
140.
by agl 14y ago
Post on implementing the (rather complex) fix: http://www.imperialviolet.org/2013/02/04/luckythirteen.html
141.
Lucky Thirteen: Breaking the TLS and DTLS Record Protocols(isg.rhul.ac.uk)
77 points by agl 14y ago|19 comments
142.
by agl 14y ago
Firstly, thanks to GitHub using HSTS on github.com (although not www.github.com), the certificate error will be fatal in Chrome and (I believe, but haven't checked) Firefox as long as you have visited GitHub previously. (It's not preloaded
143.
by agl 14y ago
Removing export ciphersuites is fine, but it's not the case that TLS randomly picks a ciphersuite from the list and therefore removing some slow ones will speed things up. Servers either use the client's most preferable ciphersuite or their
144.
by agl 14y ago
RSA keys are composite numbers. Bruteforcing them involves factoring, not trying 2^n possibilities. A bruteforce of a 1024-bit RSA key possible to be published this decade and likely by 2030. http://en.wikipedia.org/wiki/General_number_fie
145.
by agl 14y ago
Seems very similar, and at a similar price, to a family of ST boards, which have been out for a while: http://www.st.com/jp/evalboard/product/252419.jsp
146.
by agl 14y ago
€60 for shipping to US seems a little much for shipping 60 grams taking a week. Sadly none of the distributors seem to have it yet. Seems like we'll have to wait a little while longer still.
147.
by agl 14y ago
Looks like I haven't been keeping up to date even with my own colleagues' work! Thanks, I'll update the post.
148.
by agl 14y ago
The link between NSA's past work and NIST's tendencies today is weak, certainly. It's at best a rough guess on my part although, with the NSA, a rough guess is as good as we ever get :) But I am claiming that there's a hardware orientated b
149.
by agl 14y ago
SPDY header compression only compresses the headers. Bytes in the body might be vulnerable to a similar attack if the server is doing gzip compression, and that would be a fun extension to the attack, but headers and body are never compress
150.
by agl 14y ago
I'm afraid users would be angry, but they would be angry at me. Blame is assigned to the last thing to move. I'm not claiming that this is good, but it is the reality of writing browsers.

More ›