| View previous topic :: View next topic |
| Author |
Message |
D-LINC
Tux's lil' helper
Joined: 31 Jan 2011
Posts: 135
Location: Alaska
|
 Posted: Thu Jan 05, 2012 4:29 am Post subject: www.gentoo.org: no SSL |
 |
|
I was wondering: is there any particular reason www.gentoo.org does not have SSL support? Is it just the expense of the certificate?
_________________
frigidcode.com |
|
| Back to top |
|
 |
Tatsh
Apprentice
Joined: 22 Jul 2007
Posts: 187
|
| Posted: Mon Jan 09, 2012 4:48 pm Post subject: |
|
|
It's not necessary for the main site. We have nothing to hide or make sure is secure there.
If you really want the warning to go away on bugs.gentoo.org for everything (including Chrome) (as root):
| Code: | openssl s_client -connect bugs.gentoo.org:443 </dev/null 2>/dev/null | sed -n
'/BEGIN CERTIFICATE/,/END CERTIFICATE/p' >> /etc/ssl/certs/ca-certificates.crt
c_rehash |
Test with:
| Code: | | curl https://bugs.gentoo.org |
When you get an update to ca-certificates you will lose this modification. |
|
| Back to top |
|
|
D-LINC
Tux's lil' helper
Joined: 31 Jan 2011
Posts: 135
Location: Alaska
|
| Posted: Mon Jan 09, 2012 8:04 pm Post subject: |
|
|
| Tatsh wrote: | It's not necessary for the main site. We have nothing to hide or make sure is secure there.
If you really want the warning to go away on bugs.gentoo.org for everything (including Chrome) (as root):
| Code: | openssl s_client -connect bugs.gentoo.org:443 </dev/null 2>/dev/null | sed -n
'/BEGIN CERTIFICATE/,/END CERTIFICATE/p' >> /etc/ssl/certs/ca-certificates.crt
c_rehash |
Test with:
| Code: | | curl https://bugs.gentoo.org |
When you get an update to ca-certificates you will lose this modification. |
Okay, thanks for letting me know your reasoning.
I won't criticize, on account of the fact that I am still in the process of implementing SSL on my own site (and thus do not want to appear hypocritical). However, I might briefly note that the purpose of SSL is more than privacy, but also to provide assurance of authentication and integrity of the information (as I'm sure you know). You mentioned that there was nothing to make secure on the main site; however, what brought this issue to my attention was actually this page:
http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2&chap=3#webrsync-gpg
This is the page which provides instructions on setting up secure webrsync with signature checking. Since Gentoo Portage signing keys are not themselves signed by any authority which I trust, the only way for me to know that I have the correct keys is to check the fingerprints against those provided on that page. However, since that page itself is not SSL protected, there is ultimately no reassurance that data on that page came from the correct source and has not been tampered with on the way to my PC.
_________________
frigidcode.com |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 23093
|
| Posted: Tue Jan 10, 2012 4:57 am Post subject: |
|
|
| D-LINC wrote: | | This is the page which provides instructions on setting up secure webrsync with signature checking. Since Gentoo Portage signing keys are not themselves signed by any authority which I trust, the only way for me to know that I have the correct keys is to check the fingerprints against those provided on that page. However, since that page itself is not SSL protected, there is ultimately no reassurance that data on that page came from the correct source and has not been tampered with on the way to my PC. |
I ran into the same trust problem recently. As a workaround, I discovered that robbat2 posted the keys in a Bugzilla comment when he changed them on the most recent expiration. Since Bugzilla is SSL-covered[1], you could treat that as trustworthy.
[1] By an SSL certificate that is not trusted by default. If you want to be truly paranoid, how do we know that someone is not performing a MitM of Bugzilla and sending a bogus CACert certificate?  |
|
| Back to top |
|
|
D-LINC
Tux's lil' helper
Joined: 31 Jan 2011
Posts: 135
Location: Alaska
|
| Posted: Tue Jan 10, 2012 9:11 am Post subject: |
|
|
| Hu wrote: | | D-LINC wrote: | | This is the page which provides instructions on setting up secure webrsync with signature checking. Since Gentoo Portage signing keys are not themselves signed by any authority which I trust, the only way for me to know that I have the correct keys is to check the fingerprints against those provided on that page. However, since that page itself is not SSL protected, there is ultimately no reassurance that data on that page came from the correct source and has not been tampered with on the way to my PC. |
I ran into the same trust problem recently. As a workaround, I discovered that robbat2 posted the keys in a Bugzilla comment when he changed them on the most recent expiration. Since Bugzilla is SSL-covered[1], you could treat that as trustworthy.
[1] By an SSL certificate that is not trusted by default. If you want to be truly paranoid, how do we know that someone is not performing a MitM of Bugzilla and sending a bogus CACert certificate? |
"not trusted by default?" What do mean? My SSL validation tools is showing that the certificate for bugs.gentoo.org is properly validated by CACert, although the key length used is not as strong as could possibly be used. If the CA is trusted, then the site certificate cannot be subject to a MitM attack: it is mathematically impossible (at our current computing capabilities). That is the whole point of using digitally-signed certificates.
_________________
frigidcode.com |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 23093
|
| Posted: Wed Jan 11, 2012 2:55 am Post subject: |
|
|
| D-LINC wrote: | | "not trusted by default?" What do mean? My SSL validation tools is showing that the certificate for bugs.gentoo.org is properly validated by CACert, although the key length used is not as strong as could possibly be used. If the CA is trusted, then the site certificate cannot be subject to a MitM attack: it is mathematically impossible (at our current computing capabilities). That is the whole point of using digitally-signed certificates. |
I mean that if you install a clean profile of Firefox and go to https://bugs.gentoo.org/, then you will get the Firefox SSL warning page because Firefox does not recognize CACert as an authority. If you want to be picky about receiving verification only through authenticated channels, then you need some way to learn the fingerprint of the real CACert through a non-spoofable channel to a party that you trust to know that fingerprint. Otherwise, you cannot be sure you have not installed a fake CACert root authority. |
|
| Back to top |
|
|
D-LINC
Tux's lil' helper
Joined: 31 Jan 2011
Posts: 135
Location: Alaska
|
| Posted: Wed Jan 11, 2012 3:40 am Post subject: |
|
|
| Hu wrote: | | D-LINC wrote: | | "not trusted by default?" What do mean? My SSL validation tools is showing that the certificate for bugs.gentoo.org is properly validated by CACert, although the key length used is not as strong as could possibly be used. If the CA is trusted, then the site certificate cannot be subject to a MitM attack: it is mathematically impossible (at our current computing capabilities). That is the whole point of using digitally-signed certificates. |
I mean that if you install a clean profile of Firefox and go to https://bugs.gentoo.org/, then you will get the Firefox SSL warning page because Firefox does not recognize CACert as an authority. If you want to be picky about receiving verification only through authenticated channels, then you need some way to learn the fingerprint of the real CACert through a non-spoofable channel to a party that you trust to know that fingerprint. Otherwise, you cannot be sure you have not installed a fake CACert root authority. |
Okay, that makes more sense. I suppose there is a bit of a security hole in the idea of downloading the CACert root certificate from the unencrypted/unauthenticated CACert Web site. (Of course, they offer HTTPS service, but their SSL certificate is signed with their own certificate... and around in circles we go.) I suppose the best thing to do would be to travel to their main office and get them to hand you the certificate on a CD; or perhaps compare the finger print with 30 or 40 other people who have been using the certificate for a while and haven't had any trouble.
However, that doesn't quite bear on the subject at hand; of course, we recognize that somebody must be trusted ultimately (CACert) for bad or for good. However, if gentoo.org does not provide SSL service, then we are trusting nobody (or rather, everybody); every connection is an open question, because anyone could have modified the data without causing an authentication/integrity-check failure. Even self-signed would be better than nothing, because at least we would know that, once we trusted the certificate, we would always be getting content from that original source.
_________________
frigidcode.com |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Networking & Security
