Chris's Wiki :: blog/web/HTTPSOptional Commentshttps://utcc.utoronto.ca/~cks/space/blog/web/HTTPSOptional?atomcommentsDWiki2014-07-30T22:41:39ZRecent comments in Chris's Wiki :: blog/web/HTTPSOptional.By ch on /blog/web/HTTPSOptionaltag:CSpace:blog/web/HTTPSOptional:8d148eee27380b186dbe7ce4b39e4f0338d2ef38ch<div class="wikitext"><p>One "solution" obviously is DANE. At least in a dream.</p>
</div>2014-07-30T22:41:39ZBy liam, UNC-CH on /blog/web/HTTPSOptionaltag:CSpace:blog/web/HTTPSOptional:ca2149dd9cc91f0959bc49c237dd34fa27280bd3liam, UNC-CH<div class="wikitext"><p>Maximum value <em>to them</em>. We can't always know what value an attacker may be seeking. We can be compromised for as simple a reason as someone having been challenged - 'I bet you can't...'; 'I bet I can get n+1 compromised hosts before you...'. It may be revenge motivated. </p>
<p>It's most likely to be a financial value - either directly with compromised banking accounts, or value of data for resale. But it's unwise to assume that because you can't see financial riches in your site that there isn't someone out there wants something that you have.</p>
</div>2014-07-23T13:48:15ZBy Aristotle Pagaltzis on /blog/web/HTTPSOptionaltag:CSpace:blog/web/HTTPSOptional:ca85f81cb979d6bb9788da2bdd3c805a40b3c0f8Aristotle Pagaltzishttp://plasmasturm.org/<div class="wikitext"><blockquote><p>Attackers are smart – they’re going to go for the maximum value targets, not the marginal value ones.</p>
</blockquote>
<p><a href="https://en.wikipedia.org/wiki/Advanced_persistent_threat">https://en.wikipedia.org/wiki/Advanced_persistent_threat</a></p>
</div>2014-07-20T22:56:57ZBy David Magda on /blog/web/HTTPSOptionaltag:CSpace:blog/web/HTTPSOptional:f4fc1c88443d804ddb883b1b732c10fdf69e488eDavid Magdahttp://www.magda.ca/<div class="wikitext"><blockquote><p><em>The time to force people towards HTTPS is when we've solved all of these problems. In other words, when absolutely any website can make itself a certificate and then securely advertise and use that certificate.</em></p>
</blockquote>
<p>That is certainly an important feature to have. Technically one solution is DANE: place X.509 certificates into DNS, and make sure it's secured with DNSSEC. One then holds (hopefully securely) the private keys to signing one's DNS domain, and the private key to the TLS cert for the service in question.</p>
<p>This solution is by no means perfect, and the (real and perceived) problems/risks of it are available if you search, but it is a useful hand-wavy example. But it allows one to have secure communications, with a minimal number of third-party dependencies.</p>
<p>But one problem with these no-third-party-at-all solutions is: how do Internet surfers know to trust a site is the actual one they want? I'm speaking specifically of homograph attacks:</p>
<ul><li><a href="http://en.wikipedia.org/wiki/IDN_homograph_attack">http://en.wikipedia.org/wiki/IDN_homograph_attack</a></li>
</ul>
<p>So if you go to "www.mybank.com", the letter 'a' could be the proper Latin/ASCII 'a' (U+0061), or it could be the Cyrillic 'a' (U+0430). Though that problem exists even now, as you could register "mybank.com" (with IDN) and get certs for it. That is one of the problems the "Extended Validation" (EV) certificates are trying to solve: not only is the ownership of the domain looked at, but also the legal entity that is registered examined and put into the certificate.</p>
<p>It will be a good thing when anyone (good and bad) can issue certificates so that communications are "secured" from eavesdropping. But knowing that you are securely transferring data is meaningless if you're securely sending it to criminals.</p>
<p>Figuring out the trust issue is an important part of the total solution to getting rid of CAs.</p>
</div>2014-07-20T16:09:01ZBy David Magda on /blog/web/HTTPSOptionaltag:CSpace:blog/web/HTTPSOptional:e59393ae3e772ca1b78cefc7035504c661bf02faDavid Magdahttp://www.magda.ca/<div class="wikitext"><blockquote><p><em>Attackers are smart - they're going to go for the maximum value targets, not the marginal value ones.</em></p>
</blockquote>
<p>Except that "maximum value" isn't the same for everyone.</p>
<p>If you're doing industrial espionage, the "maximum value" could be to go after the internal CA of your competitor. In a slightly-related situation, RSA Security's SecurID system was attacked and hacked, and then that was leveraged to get into Lockheed Martin:</p>
<ul><li><a href="http://en.wikipedia.org/wiki/SecurID#March_2011_system_compromise">http://en.wikipedia.org/wiki/SecurID#March_2011_system_compromise</a></li>
</ul>
<p>Though one could argue that SecurID is like Verisign's CA business, and that if Lockheed Martin had been running an in-house system like Yubikey and a YubiX back-end, that would would be like LM running an in-house CA.</p>
</div>2014-07-20T15:43:59ZBy zdw on /blog/web/HTTPSOptionaltag:CSpace:blog/web/HTTPSOptional:bc3f5d37177dd49c15a01e7227156892ee11b851zdwhttp://artisancomputer.com<div class="wikitext"><p>The loaded gun analogy is a good one - as a tool a CA has both legitimate and illegitimate uses. </p>
<p>To extend the metaphor, a conventional CA is a howitzer, and your little organizational CA shoots rubber bands. The amount of damage done, and advantaged gained by gaining access to a "Everyone on the internet trusts them" CA is huge, whereas taking over even a larger corporate CA has limited value and scope. Attackers are smart - they're going to go for the maximum value targets, not the marginal value ones.</p>
<p>What it comes down to is hardening the CA creation and use process. Some ideas to resist attacks on the CA that would require minimal cost or overhead:</p>
<ul><li>Use a <a href="http://en.wikipedia.org/wiki/Shamir's_Secret_Sharing">secret sharing scheme</a> to prevent a lone/rouge actor from compromising the CA, and for keeping all pass phrases and encryption keys secure.<p>
</li>
<li>Create the CA root on an air gapped machine or set of disks, using encryption on data at rest.<p>
</li>
<li>Use a hierarchy of root and intermediate CA certs, where the validity period is fairly short to temporally contain any problems that occur. </li>
</ul>
<p>I do agree with the temptation of SSL stripping/interception would need to be addressed, but as with running your own CA, that's a policy and process issue rather than a technical one.</p>
</div>2014-07-20T14:33:38ZBy Chris Siebenmann on /blog/web/HTTPSOptionaltag:CSpace:blog/web/HTTPSOptional:46030927b60fcb2f7398d22170950ed53bce168bChris Siebenmann<div class="wikitext"><p>I actually think that organizational CAs are extremely dangerous today
because of <a href="https://utcc.utoronto.ca/~cks/space/blog/web/SSLCoreProblem">the core SSL problem</a>. Sure, your CA
is only supposed to be used for internal hosts, but there is nothing
that is actually enforcing that. This means that the security of all
HTTPS connections made inside the organization is no greater than
the security of your organizational CA and I am not really confident
about that. How many organizations are going to use well-guarded <a href="http://en.wikipedia.org/wiki/Hardware_security_module">HSMs</a>, for example?</p>
<p>(I don't think that OCSP protects you in this situation unless you've
already gone through a significant amount of CA hardening that strongly
ensures that you can only sign certificates that include your OCSP
information. If an attacker can gain enough access to sign an OCSP-less
certificate, well, they win.)</p>
<p>This also entirely neglects the pragmatic temptation for HTTPS
interception of outside secured sites on behalf of your security and
antivirus and so on people. I think that having such a loaded gun
around is a very bad idea.</p>
</div>2014-07-20T05:05:26ZBy zdw on /blog/web/HTTPSOptionaltag:CSpace:blog/web/HTTPSOptional:4d8b39c1cfc000a16da8b4e23ffe30a0097b9f2czdwhttp://artisancomputer.com<div class="wikitext"><p>A partial solution is to run your own CA, and thus controlling everything end to end. </p>
<p>While this isn't a solution that is suitable in most world-facing environments, most of the places that would employ full time IT staff have control of both ends of the connection, and thus this is reasonable. Heck, OCSP and CRL's might even have a valid place in those deployments.</p>
<p>Most business and education environments already manage end user machines (with a variety of light to heavy touches), and adding a "corporate CA" is a fairly normal and easy to implement solution - usually a one line shell script in most Unix environments, or able to be pushed via AD to most Windows systems.</p>
<p>This of course couldn't be extended to the web in general, unless being able to add arbitrary CA roots from trusted organizations (vs ones decided by OS or browser makers) became normal operating procedure, which it currently isn't.</p>
</div>2014-07-20T04:36:35Z