[Ach] Recommendations creating CSRs

[Aaron Zauner]

* mls at xlist.pw <mls at xlist.pw> [140928 08:18]:
> Hi all,
> 
> creating CSRs is one of the crypto tasks people do often. It would be nice to 
> have recommendations in the guide how to generate CSRs with openssl and what 
> parameters are recommended from a crypto perspective. Information is available 
> on sites like 
> https://shaaaaaaaaaaaaa.com/ and https://konklone.com/post/why-google-is-
> hurrying-the-web-to-kill-sha-1 but it would be helpful to have it consolidated 
> in the better crypto guide.


By the way, back when we started writing the paper (which is still a
draft by the way, contribute please if you want a final document - the
original authors are currently pretty busy with work and different
projects) none of the Certificate Authorities supported a stronger
signture algorithm than SHA1. Some of them still supplied MD5
Certificates (http://www.win.tue.nl/hashclash/rogue-ca/ - this was
in 2008!). Although TLS supports ECDSA, most Certificate Authories
do not supply ECDSA signed Certificates. Acutally I'm not aware of
any major CA that does supply ECDSA certs.


Somewhat offtopic, but relevant:

I'm repeating myself over and over again; CAs need to die, they have
been snakeoil for security from the very beginning, and everybody
that works in information security knows that being compliant with
some policy/standard does not guaratuee real security (in the case
of CAs it's 'webtrust' - which basically says 'you paid shitloads of
money, you have an HSM [stuff that has been proven to be insecure],
you have insurance: there you're now an offical CA. Inform your
favorite browser vendors and the java truststore that you're legal
now). Unfortunately there's no real alternative as of now, TACK has
not been adopted e.g. because chromium security engineers dislike the
design (they came up with hypertext key pinning instead, which is
the same thing, only limited to HTTPS/SPDY, and it doesn't seem to
get adopted anyway). I was talking to moxie as well as chrome(ium)
security folks about the issue, my best guess is it'll stay a draft
forever, although it's well engineered and the design is inherently
sexy. By the way, they also do not trust the DNSSEC/DANE hierachy
model in comparision to CAs, something I fully agree with (there are
too many attack vectors in DNSSEC hierachy compared to a central
authority, which is something the internet was never designed for
anyway, but unfortunately as of now seems to be the best option).

So in the end we'd need a couple of really good engineers and
cryptographers to come up with a new protocol for verifiable
distributed online trust that is not based on central authorities
that may be compromised.

So we're stuck with bullshit CAs and the confidence that google
detects malicous ones, because we can't (and certificate transparency
is still not an actively deployed protocol).

There's one alternative left, but it doesn't really scale for web:
TOFU (trust on first use) - that's basically what SSH does, you
accept the key once and trust that your initial connection was not
MITM'ed.

Aaron

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Digital signature
URL: <http://lists.cert.at/pipermail/ach/attachments/20140928/fccf3987/attachment.sig>