[Ach] Recommendations creating CSRs

[Aaron Zauner]

Correction: HTKP (hypertext key pinning) is an HTTP extension not
HTTPS/SPDY. SPDY is the
foundation for HTTP2 by the way. Lets see what they come up with regarding
security. Adam Langley
(Google) has been pushing in IETF for mandatory encryption (TLS) in HTTP2.
The trust issue is still
unresolved as far as I'm aware of (haven't looked into new HTTPBIS Working
Group documents since
the last IETF meeting).

HTKP is basically TOFU security with a more user friendly implementation. I
do not see it getting
accepted by IETF consensus, but I might be wrong.
https://tools.ietf.org/html/draft-ietf-websec-key-pinning


Aaron

On Sun, Sep 28, 2014 at 8:27 PM, Aaron Zauner <azet at azet.org> wrote:

> * 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 --------------
An HTML attachment was scrubbed...
URL: <http://lists.cert.at/pipermail/ach/attachments/20140928/a74bb004/attachment.html>