There are no less than 5 discernible web servers set up with different HTTPds and different SSL/TLS setups. This list is of the public Gentoo servers (excluding mirrors) that I could remember off the top of my head and showed up on http://google.com/search?q=site:gentoo.org. # Class 1 https://www.ssllabs.com/ssltest/analyze.html?d=https%3A%2F%2Fgentoo.org%2F https://www.ssllabs.com/ssltest/analyze.html?d=https%3A%2F%2Fblogs.gentoo.org%2F https://www.ssllabs.com/ssltest/analyze.html?d=https%3A%2F%2Fpackages.gentoo.org%2F https://www.ssllabs.com/ssltest/analyze.html?d=https%3A%2F%2Fsidebar.gentoo.org%2F TLS support level: "bad". - Certificate issued for *.gentoo.org by "Infra Admin" through CACert - full chain including intermediate is not sent, so it doesn't even validate as untrusted! - does not support TLS 1.1/1.2 - vulnerable to CRIME, BEAST - does not support forward security properly - session resumption is broken (default nginx setup) # Class 2 https://www.ssllabs.com/ssltest/analyze.html?d=https%3A%2F%2Fbugs.gentoo.org%2F TLS support level: "not quite as bad". - Certificate issued for *.gentoo.org by "Infra Admin" through CACert - full chain is sent, but still uses CACert MD5 certificates even though the final certificate is SHA1 - does not support TLS 1.1/1.2 - vulnerable to CRIME, BEAST - does not support forward security properly - session resumption works properly (probably due to using Apache instead of nginx) # Class 3a https://www.ssllabs.com/ssltest/analyze.html?d=https%3A%2F%2Fdevmanual.gentoo.org%2F https://www.ssllabs.com/ssltest/analyze.html?d=https%3A%2F%2Fforums.gentoo.org%2F TLS support is "good". - Certificate issued by DigiCert High Assurance CA-3 for *.gentoo.org, fingerprint 48eec4f80715574e35e99a66006cf8a611d2a89b - full chain is sent correctly with SHA-1 all the way through (should use SHA2 though) - does not support TLS 1.1/1.2 - vulnerable to CRIME, BEAST - does not support forward security properly - session resumption works properly # Class 3b https://www.ssllabs.com/ssltest/analyze.html?d=https%3A%2F%2Fplanet.gentoo.org%2F This server has the same security characteristics as class 3a, but confusingly uses a separately issued certificate (still for *.gentoo.org) with fingerprint 5da4562917ff80323e653686b54b41d9cd852538. It was issued on the same day as the previous fingerprint though, oddly enough. # Class 4 https://www.ssllabs.com/ssltest/analyze.html?d=https%3A%2F%2Fwiki.gentoo.org%2F TLS support is "very good". - Certificate issued by DigiCert High Assurance CA-3 for *.gentoo.org, fingerprint 572be126a29eae89e1b6311e24973402f4ffb138 - chain is same as 3a - actually supports TLS 1.1/1.2 - doesn't prioritize ECDHE ciphers though, so forward security is not guaranteed - Session resumption is broken, looks like the same default nginx setup. There appears to be no plausible reason why this is so, so terrible. Did anyone on the infra team communicate about this? At all? Why are half the servers on DigiCert and half on CACert? All CACert would almost make sense, due to lack of funding. But *someone* paid for real certificates, and might have even paid for two of them. And it's a wildcard. Why does only wiki.g.o support TLS 1.1/1.2? Why are half using Apache and half using nginx?
(In reply to Alex Xu from comment #0) > There are no less than 5 discernible web servers set up with different > HTTPds and different SSL/TLS setups. This list is of the public Gentoo > servers (excluding mirrors) that I could remember off the top of my head and > showed up on http://google.com/search?q=site:gentoo.org. There's well more than this list. > There appears to be no plausible reason why this is so, so terrible. Did > anyone on the infra team communicate about this? At all? How about doing some more in-depth research? > Why are half the servers on DigiCert and half on CACert? All CACert would > almost make sense, due to lack of funding. > But *someone* paid for real > certificates, and might have even paid for two of them. And it's a wildcard. We got DigiCert in JUNE 2013. This was a donation of a single wildcard multi-issue certificate from DigiCert. ALL of the digicert instances you see are this certificate. Many of the older/lower-traffic sites have NOT been migrated in our configuration, because of time to do so. There are also some sites that cannot be accommodated with this certificate, as it's only one level of wildcard, eg: bugs.gentoo.org, which REQUIRES *.bugs.gentoo.org for attachments. > Why does only wiki.g.o support TLS 1.1/1.2? > Why are half using Apache and half using nginx? Because we're a diverse team, and these machines run in diverse locations. wiki.g.o is our present-best-practice for new deployments, so if you want to offer changes to solve some issues you mention: > - doesn't prioritize ECDHE ciphers though, so forward security is not guaranteed > - Session resumption is broken, looks like the same default nginx setup. We'll certainly take those into account for other deployments, ditto changes for the Apache deployments. You also entirely missed that we run various reverse proxies & load-balancers in front of some web servers. squid, haproxy, varnish exist in various locations.
(In reply to Robin Johnson from comment #1) > (In reply to Alex Xu from comment #0) > > There are no less than 5 discernible web servers set up with different > > HTTPds and different SSL/TLS setups. This list is of the public Gentoo > > servers (excluding mirrors) that I could remember off the top of my head and > > showed up on http://google.com/search?q=site:gentoo.org. > There's well more than this list. > > > There appears to be no plausible reason why this is so, so terrible. Did > > anyone on the infra team communicate about this? At all? > How about doing some more in-depth research? Okay, okay, my statement was excessively rude. I'd like to take it back if I still can. > > Why are half the servers on DigiCert and half on CACert? All CACert would > > almost make sense, due to lack of funding. > > But *someone* paid for real > > certificates, and might have even paid for two of them. And it's a wildcard. > We got DigiCert in JUNE 2013. This was a donation of a single wildcard > multi-issue certificate from DigiCert. ALL of the digicert instances you see > are this certificate. Many of the older/lower-traffic sites have NOT been > migrated in our configuration, because of time to do so. blogs/packages/sidebar/etc, I can see why. Even without statistics, I would guess that "gentoo.org" isn't really lower-traffic, especially since stuff like the handbook and metadata.dtd are hosted on it. At least not "lower-visibility". Changing the summary to track the progress of the DigiCert upgrade, since I don't want to cause another slew of unnecessary mails. Thanks for the (relatively) well-written and fast response to my poorly-written bug report.
A more important one for you to test, because you didn't (and where handbook SHOULD be accessed), is www.gentoo.org. Any requests for 'gentoo.org' are redirected to 'www.gentoo.org', with the good DigiCert.
*** Bug 492334 has been marked as a duplicate of this bug. ***
distfiles.g.o SSL certificate expired in 2012. You may renew it or drop SSL service instead, at your choice...
distfiles.g.o never had an SSL cert explicitly issued by us, where do you see one? It's explicitly a DNS A round-robin to selected third-party mirrors, so we can't have them deploy certs. Alex: All of the original issues you reported are resolved. DigiCert & GlobalSign should be used for all Gentoo websites now, and we rank an A on the SSLLabs tests (We don't have BEAST mitigation or PFS in some cases, pending Apache 2.4 being more stable, but those aren't critical).
(In reply to Robin Johnson from comment #6) > distfiles.g.o never had an SSL cert explicitly issued by us, where do you > see one? Probably one of the mirrors without SNI that sends the same out-of-date certificate to everyone. > It's explicitly a DNS A round-robin to selected third-party mirrors, so we > can't have them deploy certs. Strictly speaking, you could create such a certificate and distribute the private key to each of the mirrors. This would arguably reduce security, since there would then be a certificate of a subdomain of gentoo.org not controlled by Gentoo. > Alex: > All of the original issues you reported are resolved. DigiCert & GlobalSign > should be used for all Gentoo websites now, and we rank an A on the SSLLabs > tests (We don't have BEAST mitigation or PFS in some cases, pending Apache > 2.4 being more stable, but those aren't critical). LGTM.
(In reply to Alex Xu (Hello71) from comment #7) > (In reply to Robin Johnson from comment #6) > > distfiles.g.o never had an SSL cert explicitly issued by us, where do you > > see one? > Probably one of the mirrors without SNI that sends the same out-of-date > certificate to everyone. Thomas: I need to know which mirror to contact them about it, but that's really a different bug, please open a new one for it. > > It's explicitly a DNS A round-robin to selected third-party mirrors, so we > > can't have them deploy certs. > Strictly speaking, you could create such a certificate and distribute the > private key to each of the mirrors. > > This would arguably reduce security, since there would then be a certificate > of a subdomain of gentoo.org not controlled by Gentoo. yeah, WONTFIX on that regard.
It seems that https://distfiles.gentoo.org/ delivers to content of https://gentoo.ussg.indiana.edu/ which uses an expired certificate. I wasn't aware that this isn't part of the gentoo owned infra, but so you may tell them to renew certificate or stop SSL.
(In reply to Thomas Bettler from comment #9) > It seems that https://distfiles.gentoo.org/ delivers to content of > https://gentoo.ussg.indiana.edu/ which uses an expired certificate. > I wasn't aware that this isn't part of the gentoo owned infra, but so you > may tell them to renew certificate or stop SSL. A DNS round-robin is required for mirroring practically by definition. If you are not happy with the services provided on alternative ports... stop connecting to them.
(In reply to Alex Xu (Hello71) from comment #10) > (In reply to Thomas Bettler from comment #9) > > It seems that https://distfiles.gentoo.org/ delivers to content of > > https://gentoo.ussg.indiana.edu/ which uses an expired certificate. > > I wasn't aware that this isn't part of the gentoo owned infra, but so you > > may tell them to renew certificate or stop SSL. > > A DNS round-robin is required for mirroring practically by definition. > > If you are not happy with the services provided on alternative ports... stop > connecting to them. A better question: Where did you get the link for https://distfiles.gentoo.org/? Specifically sith https:// instead of http://? All of our code/pages should use the non-SSL version for that host. (If DNS SRV was widely deployed, I'd use it to send HTTPS to a different server, but deployment hampers it).
Well I tried https on this server as most of the other gentoo servers also provide https. I wondered whether d.g.o also provided this as a security and integrity measure. - So I didn't find any public links for https://d.g.o But now I learned from the handbook that emerge-webrsync is the way to go.
