Crypto-related enhancements to pfSense
-
I've (finally) been able to build pfSense-2.1 and test some changes/enhancements I've been looking for. I'd like get feedback and gauge interest in trying to incorporate them into the code base. My interest has been primarily in the OpenVPN features for "small" site-to-site use. They include:
1. fixing an issue in openssl that limits RSA key lengths in client certificates to 4096 bits. This seems to be described here:
<http: rt.openssl.org="" ticket="" display.html?user="guest&pass=guest&id=319">(It isn't marked as fixed, but the author's complaint about 4096-bit keys not working appears fixed by bumping the hard-coded value +2 in the code)
The real issue is that you can't do 7680 bits (or higher), so I added a pfPorts patch to up it well above tolerating a 15360-bit RSA. In reality, people who want strong keys equivalent to AES-192 or AES-256 would probably opt for ECDH/ECDSA for performance reasons, but this limit still seems arbitrary, inadequate, and poorly coded.2. Then, updating the bit-size choices in the webConfigurator CertManager to support them.
3. Adding additional DH bit-size choices to the webConfigurator's OpenVPN server configuration screen (this also involved generating and including DH parameters files for 3072 bites, and 7680 bits).
(For those who aren't familiar, EC(C) is short for Elliptic Curve (Cryptography), a different asymmetric key technology that has been incorporated by NIST (and IETF) into approved algorithm suites in recent years. In particular, it offers far better (read practical) performance for a given cryptographic strength than RSA or DSA for certificate signing and than Diffie-Hellman for key exchange. For key strength that is equivalent to AES-192 or AES-256, RSA, DSA, and DH require key sizes – 7680 and 15360 bits, respectively -- that are impractically slow in most applications. The site <http: www.keylength.com="" en="">is a good reference for relative keysize strengths of different algorithms).
4. Adding support in OpenVPN to access the EC-based TLS cipher-suites via pfPorts patches to OpenVPN (this involves adding an "ecdh <curvename>" option to the openvpn config file so that OpenVPN can tell OpenSSL enough to enable EC-based certificates on an SSL context -- both the OpenVPN and OpenSSL code support ECC just fine under the hood). This fix seems to have been requested in OpenVPN circles for years without getting addressed: <http: sourceforge.net="" p="" openvpn="" mailman="" search="" ?q="ecdh&limit=25&page=0&sort=posted_date%20desc">5. Then, adding webConfigurator support to the OpenVPN config screens to support selecting one.
6. Adding webConfigurator support for selecting the Cryptographic Authentication hash in OpenVPN (the "auth" keyword" to go with the "cipher" keyword). OpenVPN defaults to sha1, and while you can currently change this via the "advanced options" area, this puts in it the GUI.
Something I did not add, but considered:
7. Modifying the webConfigurator CertManager to support creating EC-based certificates (both CA's and node certificates). Currently, you can import them, and all the code seems to process them happily. The CertManager uses the PHP openssl API extensions to do the actual certificate manipulation stuff, and that API library is missing the EC stuff, so it seems like too much effort to fix it</http:></curvename></http:></http:>
-
+1 from me to support these great features! Thanks for yor work so far.
-
Those are only better if you trust that ECC hasn't been compromised by the NSA, which seems to still be under debate/scrutiny.
-
Those are only better if you trust that ECC hasn't been compromised by the NSA, which seems to still be under debate/scrutiny.
Well, if you don't trust the ECC stuff, then you still would want the larger RSA key sizes, since 3072-bit RSA corresponds to AES-128 key strength. If you do trust the ECC stuff, you can get a performance boost at the larger key-equivalent sizes to 192-bit and 256-bit AES (384-bit and 512-bit ECC), since you'd need 7680-bit and 15360-bit RSA respectively. The former is slow, but probably tolerable in many applications; the latter is impractically slow.