richm44

9 ms·

31.
by richm44 11y ago
It's a pity this article is based on a false premise since it could have contributed to the discussion more usefully. What's being removed is the keygen tag, not client certificate support - the two are independent.
32.
by richm44 11y ago
Last time I checked mbed TLS omitted lots of pretty critical functionality such as certificate verification to the user - this stuff is far from trivial and is a core component of the MITM protection.
33.
by richm44 11y ago
There's a length field in a TLS record and also one in the heartbeat message itself. Heartbleed happened when the length field of the heartbeat message was longer than the length of the tls record.
34.
by richm44 11y ago
Has anyone seen a list of what tools have been added in this release?
35.
by richm44 11y ago
I do agree the situation is now better, but personally I've still found contributing to be a lot harder than it should be even for trivial fixes.
36.
by richm44 11y ago
It /was/ a drop in replacement for a single point in time but it isn't if you make use of any of the recent improvements openssl has added. For example auto selection of DH/ECDH primes and curves. Note that recently a bi
37.
by richm44 11y ago
Certainly true if you don't need them. However since code using the library as a TLS client is already partially present, support for certificate verification is definitely going to need to be added. At the moment, I'm not that im
38.
by richm44 11y ago
There's nothing wrong with client certs (other than insane complexity). However ultimately s2n is likely to need to support operation as a client too at which point things like certificate validation etc. will be needed and the amount
39.
by richm44 11y ago
Note that this library is currently only providing server functionality, and doesn't do certificate validation (in fact it appears to not do any of the X.509 parts of SSL/TLS). It's certainly interesting, but one of the reaso
40.
by richm44 11y ago
Without knowing what kind of role you're aiming for this is pretty much impossible to answer.
41.
by richm44 12y ago
At macromedia I had to list the projects I was working on outside the company - not a problem, but it needed to be done.
42.
by richm44 12y ago
Yes, please don't think I'm saying that I think protocols that start off as plain text then upgrade are a good design - I don't. All I mean there is that I've written the code required to fingerprint the implementation t
43.
by richm44 12y ago
The aim of this tool is quite different to that of ssl labs (which is a great tool btw). This is very much focussed on what the server is using (or any SSL accelerators that might be in front of it).
44.
TLS Prober – A tool for fingerprint SSL/TLS server implementations(github.com)
30 points by richm44 12y ago|5 comments
45.
by richm44 12y ago
Just a note that the QDataStream format is documented, and has been implemented in other languages such as Java. That doesn't mean that the Quassel protocol should replace IRC of course. :-)
46.
by richm44 12y ago
You can add Certificate Transparency to that list http://www.certificate-transparency.org/ though it's pretty new and barely used right now.
47.
by richm44 12y ago
Actually normal support for windows 7 ended this month. You're only getting security updates for that now, not new features.
48.
by richm44 12y ago
Dive!
49.
by richm44 12y ago
The fact you can still see the penguin is the least of ECBs problems. If you can do an adaptive chosen plain text attack then you can easily retrieve the key when ECB is used.
50.
by richm44 12y ago
How about hardware transactional memory like the new TSX instructions in the haswell chips.
51.
by richm44 12y ago
I'd just like to say thank you. Dr Dobb's was superb.
52.
by richm44 12y ago
If you're just talking about me then fair enough - the problems I've publicly identified in TLS are pretty much edge cases. Thomas on the other hand has a pretty good track record if you'd care to check.
53.
by richm44 12y ago
> It is "rubbish?" Nobody does that. Most crypto libraries are written in C or C++. > You can pre-JIT (AOT) managed code and check there too. Take a look. You'll see that for example openssl uses perl to generate assemb
54.
by richm44 12y ago
And the run-time of a managed language is 100% able to change all the timing of that if it's smart enough. It provides a guarantee of outcome not of timing. There are examples of unexpected optimisations even from static compilers such
55.
by richm44 12y ago
> The same is true with native code optimising. This is rubbish. If I use custom assembler then that's what gets run. Even if I use C code then I know what the result will be since I can actually check. > The paths should be iden
56.
by richm44 12y ago
Yeah, like I said in my other comment, I'd misread which issues have been fixed. I still stand by point that for constant time you need to be close to the metal but I think we're in agreement there anyway. I think using native cod
57.
by richm44 12y ago
"Right - it is looking more and more like truly constant time code can only be obtained by using hand written assembly or hardware. In that eventuality, I guess the core crypto code in the JVM will have to be changed to use hand writte
58.
by richm44 12y ago
Sorry, I realised I'd failed to address your other point: "What does that even mean? If you write your fail and success states to follow the same exact code paths (i.e. no branches, breaks, returns, or similar for failed) then you
59.
by richm44 12y ago
Certainly. I was referring to this blog post, http://armoredbarista.blogspot.co.uk/2014/04/easter-hack-eve... however rereading it I see he was saying it was the ones in the hardware accelerators that haven't
60.
by richm44 12y ago
Sure. The JIT's code generator isn't attempting to make code constant time, it's designed for optimising for the common case. To make the code constant time you need to be very close to the metal (and even then you really nee

More ›