3 ms·
> Using the HTTPS URI schema indicates you're asking for a secured connection. That is why the errors exist. Having a self signed certificate isn't an error in
by nadams 11y ago
> Using the HTTPS URI schema indicates you're asking for a secured connection. That is why the errors exist.
Having a self signed certificate isn't an error in the encryption negotiation (fatal) but a policy error (non-fatal). In technical terms - there is nothing wrong with a self signed certificate preventing me from having an encrypted session.
> HTTP has no security connotation hence no issues.
I think you just pointed out the problem - HTTP shouldn't exist at all - we should be migrating everything to HTTPS or some other protocol. I'm not sure letsencrypt is the answer - it might just turn into another non-maintained CA (see startssl).
> But it's far from totally broken.
The simple fact that CAs can, and have, been compromised in the past proves they are broken. If a fraudulent certificate is signed - it doesn't matter if is added to a CRL in 5 hours or 5 minutes - the bad guy has probably already used it to do damage. I'm not saying CAs are pointless - I'm advocating for a way to have a CA that is only allowed to sign certificates for certain domains - especially if I can be my own CA. Yes, I know that's not the way it works now - but surely we can modify the infrastructure to allow this.
- MichaelGG 11y ago> In technical terms - there is nothing wrong with a self signed certificate preventing me from having an encrypted session. Yes there is - the ability to verify identity and hence actually prevent MITM attacks. (And in most cases where an attacker has access to read a network, they can write to it, too.) You can't ignore key distribution no matter how annoying it is. It's really that simple. If a CA issues a false cert, that becomes a mathematical fact, and the CA gets revoked. Few entities can afford to burn lots of CAs. But anyways, plenty of people are working on this issue, with many suggestions, some even in place (cert pinning). Some trade the current CAs for total trust in the registrars. Others rely on reporting and monitoring to try to build up an idea of trustworthiness (e.g., if a site is presenting you a new cert from a different CA, especially if others aren't seeing it, alarm). Security here is simply not a binary thing.
- nadams 11y ago> Yes there is - the ability to verify identity and hence actually prevent MITM attacks. In asymmetric encryption - we both will generate a public/private key pair. We can walk up to each other, exchange USB drives containing public keys, and now we can communicate securely. We have just created a secure connection without a certificate. All the CA is a middle guy that says "Oh you want to talk to someone claiming to be Alice? Get their public key and I'll verify it as I know Alice." But really how do you trust that middle guy? > And in most cases where an attacker has access to read a network, they can write to it, too. Well maybe - put it into context. If a wifi system is open - it's extremely easy to sniff packets (shown by the success of Firesheep). ARP spoofing and other tricks are more complicated - but less likely to happen (someone would have to prop this on a table and it would be a dead giveaway that they are up to no good [1]). > You can't ignore key distribution no matter how annoying it is. I'm not ignoring it - I just want to shift it from having central CAs that can sign certificates for any domain (superfish anyone?) to CA certificates that can only sign for specific domains. Perhaps the CA certificate could be stored in DNS (even glued to the domain like NS records are)? Perhaps we keep the current CAs but force them to allow them to sign a CA cert that is restricted to a certain domain (for free or next to free)? > If a CA issues a false cert, that becomes a mathematical fact, and the CA gets revoked. That doesn't matter - if I'm a bad guy and find this I know I would only have a limited time before it's discovered. So, if I'm a smart bad guy I find a targeted attack, get the bad certificate and do my attack. By the time people figure out what happened - my attack is over and I got what I wanted. Just think of the amount of damage that could be done in a busy place with free wifi and a bad gmail.com certificate. I'm waiting for the day that happens and everyone can't understand why their [insert service provider] account was compromised... > Security here is simply not a binary thing. I never said it was - but the current system is broken [2] [3] [4] [5]. Even Schneier says it's broken - which I find he is pretty respectable in the crypto industry. [1] http://i.imgur.com/MFbOE0C.png http://i.imgur.com/MFbOE0C.png [2] http://www.theregister.co.uk/2011/04/11/state_of_ssl_analysis/ http://www.theregister.co.uk/2011/04/11/state_of_ssl_analysi... [3] https://www.schneier.com/blog/archives/2015/03/chinese_ca_issu.html https://www.schneier.com/blog/archives/2015/03/chinese_ca_is... [4] http://arstechnica.com/security/2011/09/comodo-hacker-i-hacked-diginotar-too-other-cas-breached/ http://arstechnica.com/security/2011/09/comodo-hacker-i-hack... [5] http://waf-devel.blogspot.com/2015/04/stop-blaming-chinese-web-is-broken.html http://waf-devel.blogspot.com/2015/04/stop-blaming-chinese-w...