[Ach] [oscar.koeroo at kpn.com: Applied Crypto Hardening draft]

[Tobias Dussa (SCC)]

Hi folks,

so I got some input from Oscar Koeroo.  I'll attach it verbatim below, so
everybody can pick out the stuff relevant to "their" sections. :)

---
Missing guidelines on CSR generation for PKI:
Sometimes generating CSRs in hardware modules is impossible. In that case the reader should be made aware of the services some RAs and CAs might offer in owning/keeping/having/running an MPKI solution off premise. This is just bad security practise as the private key might be just within lawful reach of a random agency. This should be prevented if possible to ensure lawful request for private keys will not scale.

Perfect Forward Secrecy
VPN appliances typically support various DH groups. This will ensure transit data to be easily intercepted. Checking the settings and pushing the right set is important for many applications. The text on PFS was also pretty limited. Can this be extended to explain that the SSL handshake setup will require a pre-master key which will later form the sending and receiving symmetric key. In the exchange the pre-master key is encryped by the servers public key. Thus asking for the private key and capturing the entire handshake and the encrypted data will yield a 100% decryption of the encrypted data. This is why PFS is so cool and through the cipher suite tuning will prevent a massive decryption potential.
Info: http://pic.dhe.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=%2Fcom.ibm.websphere.edge.doc%2Fedge%2Fcp%2Fadmingd118.htm

HSTS:
I could only see HSTS in one of the example configuration. I would add the Wikipedia text: "HTTP Strict Transport Security (HSTS) is a web security policy mechanism whereby a web server declares that complying user agents (such as a web browser) are to interact with it using only secure HTTPS connections (i.e. HTTP layered over TLS/SSL[1]). HSTS is an IETF standards track protocol and is specified in RFC 6797." Source: http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security 

SSL Libraries:
I'm not sure what you wish to express here, but have a look at libcurl. It supports 9/10 different SSL backends. More important is to prevent the following:

Peerjacking:
I couldn't find anything on RFC2818. Checking on RFC2818 doesn't come for free.

802.1x:
Also 802.1x best practises should perhaps also be included in the document. Lots of options might lead to a possibility to intercept the MSCHAPv2 or PAP (plaintext) inner authentication tunnel. In enterprise networks this is important, but also for eduroam users the SSO nature makes it an interesting target. Expressing limitation in Android, advantages in properly create OSX .mobileconfig files (with certificate pinning properties) and/or proper wpa_supplicant.conf files or even proper NAS pinning from the Windows domain service might be good practical additions to the document.
---

Cheers,
Toby.
-- 
The Most Useless Things in Aviation:
 The runway behind you.
 The air above you.
 The fuel left behind.

----

Karlsruhe Institute of Technology (KIT)
Steinbuch Centre for Computing (SCC)
KIT-CERT

Tobias Dussa
CERT Manager, CA Manager

Zirkel 2
Building 20.21
76131 Karlsruhe, Germany

Phone: +49 721 608-42479
Fax: +49 721 608-9-42479
Email: tobias.dussa at kit.edu
Web: http://www.kit.edu/

KIT – University of the State of Baden-Wuerttemberg and
National Laboratory of the Helmholtz Association