w3id.org https configuration
jdvorak001 opened this issue · 7 comments
I made a check of the https configuration of the w3id.org server using the Qualys SSL Labs server test -> https://www.ssllabs.com/ssltest/analyze.html?d=w3id.org
I'm seeing grade B, which I think is sub-optimal for a piece of web infrastructure that is as important as w3id.org is.
I believe this should be improved by:
-
adding !kRSA to the SSLCipherSuite configuration option (to get forward secrecy);
-
disabling the now almost obsolete TLS v.1.0 and 1.1 by restricting SSLProtocol to just "TLSv1.2".
Best regards
Jan Dvorak
leader, CERIF & CRIS Architecture Task Group, euroCRIS
https://github.com/perma-id/w3id.org/tree/master/cerif
I think the apache setup was different before and addressed this, but went back to defaults when apache was reinstalled at one point. Hard to tell what is the most recent best practice. Would be nice if the defaults just did the best thing. I went with adding this via random Internet advice:
SSLHonorCipherOrder on
SSLCipherSuite ALL:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!RC4
I'm unsure if disabling older TLS is wise on this site. It would be good to support older clients that can't upgrade. Newer clients will use newer protocols. Major sites like google still have older TLS enabled. We've had real world issues with apps that couldn't even handle let's encrypt certs, so I imagine older TLS support could be an issue too. I added a log to see what protocols are being used, and will check back on that later.
Leave this open for now. Good spot for complaints if the cipher suite change broke something.
Also, if anyone thinks the suites should be explicit vs that "ALL", suggest an alternative. Thanks.
Not encouraging older TLS use, but accepting it if it is used, seems like a pragmatic approach. Apache logs are almost all TLSv1.2 in last ~20h or so. 286 TLSv1 requests, some from ssllabs testing, a bunch from attackers poking at wordpress urls that don't exist or similar. But the rest look like the could be real data. Maybe all bots, who knows. I'll leave that running for a while. This is the sort of thing I'm tempted to just revisit in a year.
It hasn't been running for a full year yet, but it's time to revisit this. The certificate for w3id.org was soon to expire so we switched over to letsencrypt. I imagine this will be mostly transparent to everyone, but if anyone has a problem, let us know.
Does anyone have thoughts on what the current apache configuration should be?
certbot wants to use something like this:
SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384
SSLHonorCipherOrder off
SSLSessionTickets off
SSLOptions +StrictRequireBut the config was left as before to avoid service disruption:
SSLHonorCipherOrder on
SSLCipherSuite ALL:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!RC4That does still cap the ssllabs score at B, but modern clients should do the right thing.
To provide some insight into what's being used, here's the recent version stats:
5 TLSv1.1
27 -
5677 TLSv1
498992 TLSv1.2
958476 TLSv1.3
And version+suite stats:
1 TLSv1.2 ECDHE-RSA-AES128-SHA
2 TLSv1.2 DHE-RSA-AES256-SHA256
5 TLSv1.1 ECDHE-RSA-AES256-SHA
27 - -
106 TLSv1.2 ECDHE-RSA-AES128-SHA256
129 TLSv1.2 ECDHE-RSA-CHACHA20-POLY1305
161 TLSv1.2 ECDHE-RSA-AES256-SHA384
181 TLSv1 ECDHE-RSA-AES128-SHA
1139 TLSv1.2 DHE-RSA-AES256-GCM-SHA384
2308 TLSv1 ECDHE-RSA-AES256-SHA
3188 TLSv1 DHE-RSA-AES256-SHA
23504 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256
473947 TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384
958470 TLSv1.3 TLS_AES_256_GCM_SHA384
I imagine most of that is bots, but TLSv1 usage is not zero. While we could analyze what that 0.388% TLSv1 usage is for, perhaps we should just shut that off at this point and maybe those clients will adapt? Or at least shut it off until someone lets us know it's needed for a niche purpose. Other than disabling certain protocols, I'm not sure how those other suggested config lines would effect service users.
Comments?
I noticed that while accessing w3id through https with prepended "www" major browsers like Chrome output a security warning with the message NET::ERR_CERT_COMMON_NAME_INVALID.
It seems to be that there is no SSL certificate in place for https://www.w3id.org/ecsel-dr but only https://w3id.org/ecsel-dr. Is this behavior intended and can you replicate it?