Crypto++ Website, Wiki, and Source Control cut-over
Jeffrey Walton
The Crypto++ Website, Wiki, and Source Control cut-over happened without much fanfare.
Crypto++ now resides in its own virtual machine, disgorged from shared hosting environments. The VM provides the WikiMedia software, so its hosting the Wiki too.
Source control is now provided by GitHub, and that cut-over occurred back in June/July 2015. The links on the Home page have been updated.
There's a CAcert (https://www.cacert.org/) issued certificate on the website, and the browser mixed-content issues have been resolved. Its hit-or-miss whether you will get browser warnings for CAcert warez. Firefox is OK, but Safari complains. The site's key fingerprints are:
* SHA1: 77:61:4A:23:81:93:26:5A:34:2E:1E:BC:8A:C8:38:A9:85:A4:FD:90
* SHA256: A8:BC:CA:3F:BF:73:4A:80:18:5B:96:80:75:9B:30:AA:F4:A9:91:CB:8F:D6:AE:E0:13:28:30:CF:20:2A:ED:3C
If needed/desired you an install the CAcert Class 1 Root Signing Certificate from https://www.cacert.org/index.php?id=3. The fingerprints of interest are:
* SHA1 Fingerprint: 13:5C:EC:36:F4:9C:B8:E9:3B:1A:B2:70:CD:80:88:46:76:CE:8F:33
* MD5 Fingerprint: A6:1B:37:5E:39:0D:9C:36:54:EE:BD:20:31:46:1F:6B
Don't get your feathers too ruffled over the CAcert. The web security model has bigger problems, so a little known CA is one of the least of our worries. The bigger problems include "interception is a valid use case", where user phishing is embraced; "Organizational Validated (OV) certificates", where organizations like Google or CNNIC mint certificates for web properties they don't own or control (and they did away with the third party auditor; and the audit trail never existed); and "Host Public Key Pinning with Overrides (RFC 7469)", where an attacker can break a known good pinset (and the reporting is suppressed, too).
We are going to attempt to practice key-continuity for the site. That means the only time you should suspect a problem is when the public key changes. If the public key remains the same (and in the absence of a announced key compromise), you can assume everything is OK. Browsers are brain dead and and don't have minimal intelligence (they could have had it, but the HPKP Overrides destroyed the security property).
Jeff
Jean-Pierre Münch
Hi Everyone,
The Crypto++ Website, Wiki, and Source Control cut-over happened without much fanfare.
Crypto++ now resides in its own virtual machine, disgorged from shared hosting environments. The VM provides the WikiMedia software, so its hosting the Wiki too.
Source control is now provided by GitHub, and that cut-over occurred back in June/July 2015. The links on the Home page have been updated.
There's a CAcert (https://www.cacert.org/) issued certificate on the website, and the browser mixed-content issues have been resolved. Its hit-or-miss whether you will get browser warnings for CAcert warez. Firefox is OK, but Safari complains.
May I further "criticize" that the HTTPS version of the wiki causes a mixed content warning although it only loads from cryptopp.com and www.cryptopp.com?
May I further question the web server's cipher suite preference? It prefers TLS_RSA_WITH_AES_256_CBC_SHA over TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 it looks like it's configured like something HIGH:MEDIUM:@STRENGTH
Personally I'd prefer "EECDH+aRSA+AESGCM:EECDH+aRSA+AES:+EECDH+aRSA+AES+SHA1" which enforces ECDHE and RSA and prefers GCM over CBC+SHA2 over CBC+SHA1.
And to enhance trust we may also want to deploy DNSSEC / DANE (TLSA) and HSTS?
BR
JPM
The site's key fingerprints are:
* SHA1: 77:61:4A:23:81:93:26:5A:34:2E:1E:BC:8A:C8:38:A9:85:A4:FD:90
* SHA256: A8:BC:CA:3F:BF:73:4A:80:18:5B:96:80:75:9B:30:AA:F4:A9:91:CB:8F:D6:AE:E0:13:28:30:CF:20:2A:ED:3C
If needed/desired you an install the CAcert Class 1 Root Signing Certificate from https://www.cacert.org/index.php?id=3. The fingerprints of interest are:
* SHA1 Fingerprint: 13:5C:EC:36:F4:9C:B8:E9:3B:1A:B2:70:CD:80:88:46:76:CE:8F:33
* MD5 Fingerprint: A6:1B:37:5E:39:0D:9C:36:54:EE:BD:20:31:46:1F:6B
Don't get your feathers too ruffled over the CAcert. The web security model has bigger problems, so a little known CA is one of the least of our worries. The bigger problems include "interception is a valid use case", where user phishing is embraced; "Organizational Validated (OV) certificates", where organizations like Google or CNNIC mint certificates for web properties they don't own or control (and they did away with the third party auditor; and the audit trail never existed); and "Host Public Key Pinning with Overrides (RFC 7469)", where an attacker can break a known good pinset (and the reporting is suppressed, too).
We are going to attempt to practice key-continuity for the site. That means the only time you should suspect a problem is when the public key changes. If the public key remains the same (and in the absence of a announced key compromise), you can assume everything is OK. Browsers are brain dead and and don't have minimal intelligence (they could have had it, but the HPKP Overrides destroyed the security property).
Jeff
--
--
You received this message because you are subscribed to the "Crypto++ Users" Google Group.
To unsubscribe, send an email to cryptopp-user...@googlegroups.com.
More information about Crypto++ and this group is available at http://www.cryptopp.com.
---
You received this message because you are subscribed to the Google Groups "Crypto++ Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cryptopp-user...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Jeffrey Walton
May I further "criticize" that the HTTPS version of the wiki causes a mixed content warning although it only loads from cryptopp.com and www.cryptopp.com?
OK, I thought we cleared the mixed content warnings. Can you provide specific information, like a URL that produces the mixed content warning?
May I further question the web server's cipher suite preference? It prefers TLS_RSA_WITH_AES_256_CBC_SHA over TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 it looks like it's configured like something HIGH:MEDIUM:@STRENGTH
Personally I'd prefer "EECDH+aRSA+AESGCM:EECDH+aRSA+AES:+EECDH+aRSA+AES+SHA1" which enforces ECDHE and RSA and prefers GCM over CBC+SHA2 over CBC+SHA1.
Here are the two settings of interest from /etc/httpd/conf.d/ssl.conf :
SSLProtocol -all +TLSv1 +TLSv1.1 +TLSv1.2
SSLCipherSuite HIGH:!aNULL:!MD5:!RC4
Out of curiosity, what part of the site needs forward secrecy? Everything that can be downloaded over HTTPS is available over HTTP, and its available to everyone.
Jeff
Jean-Pierre Münch
May I further "criticize" that the HTTPS version of the wiki causes a mixed content warning although it only loads from cryptopp.com and www.cryptopp.com?
OK, I thought we cleared the mixed content warnings. Can you provide specific information, like a URL that produces the mixed content warning?
May I further question the web server's cipher suite preference? It prefers TLS_RSA_WITH_AES_256_CBC_SHA over TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 it looks like it's configured like something HIGH:MEDIUM:@STRENGTH
Personally I'd prefer "EECDH+aRSA+AESGCM:EECDH+aRSA+AES:+EECDH+aRSA+AES+SHA1" which enforces ECDHE and RSA and prefers GCM over CBC+SHA2 over CBC+SHA1.
Here are the two settings of interest from /etc/httpd/conf.d/ssl.conf :
SSLProtocol -all +TLSv1 +TLSv1.1 +TLSv1.2
The standard server test tells me we can drop it: https://www.ssllabs.com/ssltest/analyze.html?d=cryptopp.com
as every client either negotiates v1.2 or v1.0 but none bothers negotiating v1.1.
SSLCipherSuite HIGH:!aNULL:!MD5:!RC4
Out of curiosity, what part of the site needs forward secrecy? Everything that can be downloaded over HTTPS is available over HTTP, and its available to everyone.
BR
JPM
Jeffrey Walton
Well, I had this warning when I wrote the mail, but I can't reproduce right now. I think you may have fixed it or I interrupted you while you we're fixing it :)May I further "criticize" that the HTTPS version of the wiki causes a mixed content warning although it only loads from cryptopp.com and www.cryptopp.com?
OK, I thought we cleared the mixed content warnings. Can you provide specific information, like a URL that produces the mixed content warning?
Yeah, this may have been the logo on the wiki. It was being served over HTTP. It was one of the last changes made.
But I was not getting a mixed content warning about it from Firefox (the half shield). Instead, I got the site does not identify itself warning (the triangle with the exclamation point). I wrote that off as a non-EV certificate.
I'm not sure if we need to support TLS v1.1 or if we can drop it.
May I further question the web server's cipher suite preference? It prefers TLS_RSA_WITH_AES_256_CBC_SHA over TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 it looks like it's configured like something HIGH:MEDIUM:@STRENGTH
Personally I'd prefer "EECDH+aRSA+AESGCM:EECDH+aRSA+AES:+EECDH+aRSA+AES+SHA1" which enforces ECDHE and RSA and prefers GCM over CBC+SHA2 over CBC+SHA1.
Here are the two settings of interest from /etc/httpd/conf.d/ssl.conf :
SSLProtocol -all +TLSv1 +TLSv1.1 +TLSv1.2
The standard server test tells me we can drop it: https://www.ssllabs.com/ssltest/analyze.html?d=cryptopp.com
as every client either negotiates v1.2 or v1.0 but none bothers negotiating v1.1.
I don't think it matters, and it simplifies things for non-conforming TLS user agents. That is, most of the world uses TLS record layer version as a "min" version, and the client's TLS protocol version as a "max" version. There's no room for wholes.
The IETF refuses to document the "min" and "max" TLS versions even though most user agents conform to it (https://www.ietf.org/mail-archive/web/tls/current/msg16440.html). Instead, we get those silly browser dances like TLS_FALLBACK_SCSV.
Jeff