Summary: | Migrate old *.gentoo.org servers to new DigiCert certificate | ||
---|---|---|---|
Product: | Gentoo Infrastructure | Reporter: | Alex Xu (Hello71) <alex_y_xu> |
Component: | Other web server issues | Assignee: | Gentoo Infrastructure <infra-bugs> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | thomas.bettler |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 223347, 367249, 410569, 451506, 469888, 470054 |
Description
Alex Xu (Hello71)
2013-08-29 02:39:29 UTC
(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. |