<story><title>Launching in 2015: A Certificate Authority to Encrypt the Entire Web</title><url>https://www.eff.org/deeplinks/2014/11/certificate-authority-encrypt-entire-web</url></story><parent_chain><item><author>IgorPartola</author><text>&amp;gt; Encrypted (Certified)    COOL GREEN&lt;p&gt;I think we can agree that this case is correct. If you have a properly vetted cert, more power to you. The browser should tell your users that you do own this domain.&lt;p&gt;&amp;gt; Encrypted (Self-Signed)  EVIL RED&lt;p&gt;Not quite. Your user does have the ability to permanently trust this certificate. However, if I am trying to access gmail.com over HTTPS, I better not get this error. Otherwise, I know for a fact someone is messing with me.&lt;p&gt;&amp;gt; Unencrypted              NOTHING &amp;#x2F; NEUTRAL CHROME&lt;p&gt;This case should be eliminated. We need to stop publishing stuff over HTTP. Period. The browsers should start fast tracking dropping support for HTTP altogether so we don&amp;#x27;t even have to think about this case.&lt;p&gt;Now the solution for case #2 is that every time you buy a domain, your registrar should issue you a wildcard cert for that domain. Moreover, you should be able to use that private key + cert to sign additional certs for individual subdomains. That way we can eliminate all the CA&amp;#x27;s. We would essentially use the same infrastructure that already supports domain name registration and DNS instead of funding a completely parallel, yet deeply flawed CA industry. As a bonus, this way only your registrar and you may issue certs for your domain.&lt;p&gt;This is all castles in the sky, but IMO that&amp;#x27;s the correct solution.</text></item><item><author>rufb</author><text>So this is where we stand:&lt;p&gt;&lt;pre&gt;&lt;code&gt;    Encrypted (Certified)    COOL GREEN
    Encrypted (Self-Signed)  EVIL RED
    Unencrypted              NOTHING &amp;#x2F; NEUTRAL CHROME
&lt;/code&gt;&lt;/pre&gt;
I think there&amp;#x27;s a pretty blatant antipattern here, and I&amp;#x27;m not talking about colourblind-proofing the browser chrome.</text></item><item><author>pilif</author><text>&lt;i&gt;&amp;gt; A self signed certificate warning means &amp;quot;Warning! The admin on the site you&amp;#x27;re connecting to wants this conversation to be private but it hasn&amp;#x27;t been proven that he has 200 bucks for us to say he&amp;#x27;s cool&amp;quot;&lt;/i&gt;&lt;p&gt;no. It means &amp;quot;even though this connection is encrypted, there is no way to tell you whether you are currently talking to that site or to NSA which is forwarding all of your traffic to the site you&amp;#x27;re on&amp;quot;.&lt;p&gt;Treating this as a grave error IMHO is right because by accepting the connection over SSL, you state that the conversation between the user agent and the server is meant to be private.&lt;p&gt;Unfortunately, there is no way to guarantee that to be true if the identity of the server certificate can&amp;#x27;t somehow be tied to the identity of the server.&lt;p&gt;So when you accept the connection unencrypted, you tell the user agent &amp;quot;hey - everything is ok here - I don&amp;#x27;t care about this conversation to be private&amp;quot;, so no error message is shown.&lt;p&gt;But the moment you accept the connection over ssl, the user agent assumes the connection to be intended to be private and failure to assert identity becomes a terminal issue.&lt;p&gt;This doesn&amp;#x27;t mean that the CA way of doing things is the right way - far from it. It&amp;#x27;s just the best that we currently have.&lt;p&gt;The solution is absolutely not to have browsers accept self-signed certificates though. The solution is something nobody hasn&amp;#x27;t quite come up with.</text></item><item><author>digitalsushi</author><text>This certificate industry has been such a racket. It&amp;#x27;s not even tacit that there are two completely separate issues that certificates and encryption solve.  They get conflated and non technical users rightly get confused about which thing is trying to solve a problem they aren&amp;#x27;t sure why they have.&lt;p&gt;The certificate authorities are quite in love that the self-signed certificate errors are turning redder, bolder, and bigger.  A self signed certificate warning means &amp;quot;Warning! The admin on the site you&amp;#x27;re connecting to wants this conversation to be private but it hasn&amp;#x27;t been proven that he has 200 bucks for us to say he&amp;#x27;s cool&amp;quot;.&lt;p&gt;But so what if he&amp;#x27;s cool?  Yeah I like my banking website to be &amp;quot;cool&amp;quot; but for 200 bucks I can be just as &amp;quot;cool&amp;quot;.  A few years back the browsers started putting extra bling on the URL bar if the coolness factor was high enough - if a bank pays 10,000 bucks for a really cool verification, they get a giant green pulsating URL badge.  And they should, that means someone had to fax over vials of blood with the governor&amp;#x27;s seal that it&amp;#x27;s a legitimate institute in that state or province.  But my little 200 dollar, not pulsating but still green certificate means &amp;quot;yeah digitalsushi definitely had 200 bucks and a fax machine, or at least was hostmaster@digitalsushi.com for damned sure&amp;quot;.&lt;p&gt;And that is good enough for users.  No errors?  It&amp;#x27;s legit.&lt;p&gt;What&amp;#x27;s the difference between me coughing up 200 bucks to make that URL bar green, and then bright red with klaxons cause I didn&amp;#x27;t cough up the 200 bucks to be sure I am the owner of a personal domain?  Like I said, a racket.  The certificate authorities love causing a panic.  But don&amp;#x27;t tell me users are any safer just &amp;#x27;cause I had 200 bucks.  They&amp;#x27;re not.&lt;p&gt;The cert is just for warm and fuzzies.  The encryption is to keep snoops out.  If I made a browser, I would have 200 dollar &amp;quot;hostmaster&amp;quot; verification be some orange, cautious URL bar - &amp;quot;this person has a site that we have verified to the laziest extent possible without getting sued for not even doing anything at all&amp;quot;.  But then I probably wouldn&amp;#x27;t be getting any tips in my jar from the CAs at the end of the day.</text></item></parent_chain><comment><author>kybernetikos</author><text>&amp;gt;&amp;gt; Encrypted (Certified)    COOL GREEN&lt;p&gt;&amp;gt; I think we can agree that this case is correct. If you have a properly vetted cert, more power to you. The browser should tell your users that you do own this domain.&lt;p&gt;Maybe.  I just checked my browser and it already trusts more than 100 certificate authorities from all around the world, including some companies that I don&amp;#x27;t trust, some governments that I don&amp;#x27;t trust, but mainly composed of organisations I&amp;#x27;ve never heard of.  Even in a good system, there would occasionally be leaks etc, but this mess of promiscuous trust is clearly insane.</text></comment>
<story><title>Launching in 2015: A Certificate Authority to Encrypt the Entire Web</title><url>https://www.eff.org/deeplinks/2014/11/certificate-authority-encrypt-entire-web</url></story><parent_chain><item><author>IgorPartola</author><text>&amp;gt; Encrypted (Certified)    COOL GREEN&lt;p&gt;I think we can agree that this case is correct. If you have a properly vetted cert, more power to you. The browser should tell your users that you do own this domain.&lt;p&gt;&amp;gt; Encrypted (Self-Signed)  EVIL RED&lt;p&gt;Not quite. Your user does have the ability to permanently trust this certificate. However, if I am trying to access gmail.com over HTTPS, I better not get this error. Otherwise, I know for a fact someone is messing with me.&lt;p&gt;&amp;gt; Unencrypted              NOTHING &amp;#x2F; NEUTRAL CHROME&lt;p&gt;This case should be eliminated. We need to stop publishing stuff over HTTP. Period. The browsers should start fast tracking dropping support for HTTP altogether so we don&amp;#x27;t even have to think about this case.&lt;p&gt;Now the solution for case #2 is that every time you buy a domain, your registrar should issue you a wildcard cert for that domain. Moreover, you should be able to use that private key + cert to sign additional certs for individual subdomains. That way we can eliminate all the CA&amp;#x27;s. We would essentially use the same infrastructure that already supports domain name registration and DNS instead of funding a completely parallel, yet deeply flawed CA industry. As a bonus, this way only your registrar and you may issue certs for your domain.&lt;p&gt;This is all castles in the sky, but IMO that&amp;#x27;s the correct solution.</text></item><item><author>rufb</author><text>So this is where we stand:&lt;p&gt;&lt;pre&gt;&lt;code&gt;    Encrypted (Certified)    COOL GREEN
    Encrypted (Self-Signed)  EVIL RED
    Unencrypted              NOTHING &amp;#x2F; NEUTRAL CHROME
&lt;/code&gt;&lt;/pre&gt;
I think there&amp;#x27;s a pretty blatant antipattern here, and I&amp;#x27;m not talking about colourblind-proofing the browser chrome.</text></item><item><author>pilif</author><text>&lt;i&gt;&amp;gt; A self signed certificate warning means &amp;quot;Warning! The admin on the site you&amp;#x27;re connecting to wants this conversation to be private but it hasn&amp;#x27;t been proven that he has 200 bucks for us to say he&amp;#x27;s cool&amp;quot;&lt;/i&gt;&lt;p&gt;no. It means &amp;quot;even though this connection is encrypted, there is no way to tell you whether you are currently talking to that site or to NSA which is forwarding all of your traffic to the site you&amp;#x27;re on&amp;quot;.&lt;p&gt;Treating this as a grave error IMHO is right because by accepting the connection over SSL, you state that the conversation between the user agent and the server is meant to be private.&lt;p&gt;Unfortunately, there is no way to guarantee that to be true if the identity of the server certificate can&amp;#x27;t somehow be tied to the identity of the server.&lt;p&gt;So when you accept the connection unencrypted, you tell the user agent &amp;quot;hey - everything is ok here - I don&amp;#x27;t care about this conversation to be private&amp;quot;, so no error message is shown.&lt;p&gt;But the moment you accept the connection over ssl, the user agent assumes the connection to be intended to be private and failure to assert identity becomes a terminal issue.&lt;p&gt;This doesn&amp;#x27;t mean that the CA way of doing things is the right way - far from it. It&amp;#x27;s just the best that we currently have.&lt;p&gt;The solution is absolutely not to have browsers accept self-signed certificates though. The solution is something nobody hasn&amp;#x27;t quite come up with.</text></item><item><author>digitalsushi</author><text>This certificate industry has been such a racket. It&amp;#x27;s not even tacit that there are two completely separate issues that certificates and encryption solve.  They get conflated and non technical users rightly get confused about which thing is trying to solve a problem they aren&amp;#x27;t sure why they have.&lt;p&gt;The certificate authorities are quite in love that the self-signed certificate errors are turning redder, bolder, and bigger.  A self signed certificate warning means &amp;quot;Warning! The admin on the site you&amp;#x27;re connecting to wants this conversation to be private but it hasn&amp;#x27;t been proven that he has 200 bucks for us to say he&amp;#x27;s cool&amp;quot;.&lt;p&gt;But so what if he&amp;#x27;s cool?  Yeah I like my banking website to be &amp;quot;cool&amp;quot; but for 200 bucks I can be just as &amp;quot;cool&amp;quot;.  A few years back the browsers started putting extra bling on the URL bar if the coolness factor was high enough - if a bank pays 10,000 bucks for a really cool verification, they get a giant green pulsating URL badge.  And they should, that means someone had to fax over vials of blood with the governor&amp;#x27;s seal that it&amp;#x27;s a legitimate institute in that state or province.  But my little 200 dollar, not pulsating but still green certificate means &amp;quot;yeah digitalsushi definitely had 200 bucks and a fax machine, or at least was hostmaster@digitalsushi.com for damned sure&amp;quot;.&lt;p&gt;And that is good enough for users.  No errors?  It&amp;#x27;s legit.&lt;p&gt;What&amp;#x27;s the difference between me coughing up 200 bucks to make that URL bar green, and then bright red with klaxons cause I didn&amp;#x27;t cough up the 200 bucks to be sure I am the owner of a personal domain?  Like I said, a racket.  The certificate authorities love causing a panic.  But don&amp;#x27;t tell me users are any safer just &amp;#x27;cause I had 200 bucks.  They&amp;#x27;re not.&lt;p&gt;The cert is just for warm and fuzzies.  The encryption is to keep snoops out.  If I made a browser, I would have 200 dollar &amp;quot;hostmaster&amp;quot; verification be some orange, cautious URL bar - &amp;quot;this person has a site that we have verified to the laziest extent possible without getting sued for not even doing anything at all&amp;quot;.  But then I probably wouldn&amp;#x27;t be getting any tips in my jar from the CAs at the end of the day.</text></item></parent_chain><comment><author>jameshart</author><text>There&amp;#x27;s no such thing in X509 as a cert which is authorized only to sign certs within a certain subdomain. A CA is either trusted or not; if it&amp;#x27;s trusted, it can sign off on a cert for www.google.com.&lt;p&gt;A system where there&amp;#x27;s a .com root cert that can sign authority certs for .com subdomains, which themselves can only sign for their own subdomains - that&amp;#x27;s a great idea. Not part of the standard, though.</text></comment>