Hanno Böck

I'm pretty impressed by ASAN (and MSAN, UBSAN, etc.) It catches uses after free trivially, as long as you have unit tests, which I always do.

I wonder at the cost of these 2 strategies, for the huge legacy of C/C++ infrastructure we have:

1) refactoring it to be testable, adding unit tests, adding test coverage automation, adding ASAN/MSAN builds, etc. (LLVM is a game changer IMO in addition to C++ 11; things have changed so much in the last 5 years)

2) rewriting it in Rust

I'm not claiming anything specific, but #2 seems strictly more expensive, since you still need unit tests for logic bugs anyway (and yes I have written OCaml and get that you can replace control flow with typed data, etc.) #1 also has a straightforward migration path.

More to the point, most open source software has TERRIBLE test hygiene. If they don't even have time to write tests, I wonder how they will have time to rewrite in Rust.

I'm all for new software in Rust, but I'm thinking about all of Linux user space, web servers, web browsers, every programming language implementation, etc.

Also, fuzzing can be combined with ASAN.

https://blog.hboeck.de/archives/868-How-Heartbleed-couldve-been-found.html

Yes it would be better to know these things statically and not dynamically, and I'm glad that Rust has innovated in this space.

Wikipedia has a good description on what OCSP Stapling is[1] and how it works. When I read the Apache projects' WONTFIX reason, I presumed that it was related to how plain OCSP requires the client to "phone home" in order to check whether a certificate has been revoked or not – which has implications for the privacy of the browser.

However, now that I know OCSP Stapling works (the web server caches and proxies time-stamped OCSP responses that are signed by the CA), the Apache position is much less reasonable. As a Let’s Encrypt user, I “phone home” every couple of months to renew my X.509 key and certificate. That’s not a privacy concern for me or anyone else who happens to browse my site.

I also found a good article by Hanno Böck[2] which provides more details on how OCSP Stapling is thoroughly broken on Apache as described by tialaramex).

[1] https://en.wikipedia.org/wiki/OCSP_stapling

[2] https://blog.hboeck.de/archives/886-The-Problem-with-OCSP-Stapling-and-Must-Staple-and-why-Certificate-Revocation-is-still-broken.html

Actually, libressl is practical drop-in replacement of openssl if you use only sane parts of openssl's functionality.

Biggest problem now is some upstream softwares still depends on insanity Openbsd devs nuked away, like RAND_egd() or won't admit that libressl actually exist :)

(https://devsonacid.wordpress.com/2014/07/12/how-compatible-is-libressl/, https://blog.hboeck.de/archives/851-LibreSSL-on-Gentoo.html)

But situation is changing as more and more upstream developers abandon those APIs : https://github.com/gentoo/libressl/blob/master/README.md

And I guess this is cool thing about libressl: even if it fails to replace openssl for real good, it is still forcing others to advance toward right direction (remember the linux fork fuss last year? You can disagree with me but I myself consider it linux's 'fault' not to have consistent mechanism of extracting entropy....it doesn't have to be arc4random but it could have been better in the first place if this IMO)

> Still think it was 'cosmic rays' on SKS's machines?

Just FYI, this kind of stuff seems to have been done before, with vulnerable keys found:

https://eprint.iacr.org/2012/064.pdf (2012),

https://factorable.net/

(these two are mentioned and linked to from https://blog.hboeck.de/archives/872-About-the-supposed-factoring-of-a-4096-bit-RSA-key.html)

And (off-topic) if you are wondering why some of your recent comments are being downvoted so much, it's probably because of the tone (saying things such as "good job repeating my research" when work of the same kind with results of the same kind had been done before (see above.))

Still an interesting result and curious re. SKS servers (not) checking subkeys etc...

also https://news.ycombinator.com/item?id=9562170

I don't even understand why people use antivirus software. Sure, if you're on an ancient version of your OS, like Windows XP, then it might serve some purpose, but assuming modern versions of these operating systems, antivirus software does more harm than good.

Worried about browser extensions?

Another problem is that popular antivirus software are also installing their own root certificate so they can MITM secure HTTPS connections.

For example Bitdefender is able to inspect and modify your Google search result without installing a browser extension. And this is a common practice. See for example:

https://blog.hboeck.de/archives/869-How-Kaspersky-makes-you-vulnerable-to-the-FREAK-attack-and-other-ways-Antivirus-software-lowers-your-HTTPS-security.html

Mike here using old openid account, as I'm replying too fast.

The CA handles the verification, hence the difference in price. Symantec/Verisign is the most expensive, Digicert is in the middle, Comodo and the Symantec budget brands are the cheapest.

As mentioned elsewhere, I do have code written against the Comodo API, and it would be a lot more profitable to use them. However I (and the tech companies I'm targeting, eg, Stripe, GitHub) use Digicert certs, mainly for reasons of verification speed but also business practice compared to competitors, eg, Comodo: https://blog.hboeck.de/archives/866-PrivDog-wants-to-protect-your-privacy-by-sending-data-home-in-clear-text.html