5 ms·

I think SSL certificates need to be replaced. Security can NOT be designed with the 'good guy' in mind. if it can be broken at all we need an alternative.

satai 10y ago
The certificates are OK. The issue is the way they are signed and distributed. Lots of issues with the current PK infrastructure is limited by the certificate transparency.
- lclarkmichalek 10y ago
  The certificates have their own, independent problems (who thinks x509 is a good format?)
  - sitkack 10y ago
    The NSA
- asdfasdfasdfa12 10y ago
  it is too hard for me to believe that root ca's have not been compromised when anyone working at these companies could likely easily take it without anyone noticing. I do not think transparency has anything at all to do with it. I think an encryption solutions that cannot be 'broken' for decryption is far more required than one that has the 'good guy' in mind. I do not find it an acceptable solution for critical data.
  - satai 10y ago
    Not any transparency. Certificate transparency. https://en.m.wikipedia.org/wiki/Certificate_Transparency https://en.m.wikipedia.org/wiki/Certificate_Transparency
    - asdfasdfasdfa12 10y ago
      I think we are talking on different lines of thought. I am not concerned with certificate transparency... as the article you point out says it can take a long time [years] before it is found to be compromised. the fact of the matter is, if ssl decryption is possible on the fly, we need a different solution for encryption, this include the use of credit card chip. an encryption scheme cannot be designed to be broken and expect everything to be 'secure' EDIT: I am not being allowed to reply. excuse me, I think you need to read what I wrote more carefully. I do not care about certificate transparency. I must not be communicating clearly I will try again.. I am not referring to the ability to issue a new certificate. I'm talking about the ability to perform SSL decryption without the end user knowing. you do not need to issue a new certificate to do this, you just need the end user to have trusted a new root CA... which brings us to this article where another company is issuing a root CA. do you trust everyone in your 'trusted root ca's on your computer? Here are some ways to untrust certs [0][1]and another conversation on this [2] [0]http://unix.stackexchange.com/questions/285784/untrusting-an-intermediate-ca-in-linux http://unix.stackexchange.com/questions/285784/untrusting-an... [1] https://blog.filippo.io/untrusting-an-intermediate-ca-on-os-x/ https://blog.filippo.io/untrusting-an-intermediate-ca-on-os-... [2] https://news.ycombinator.com/item?id=11781915 https://news.ycombinator.com/item?id=11781915
      - satai 10y ago
        You can pretty much trust all the root CAs that provide Certificate Transparency. If such a CA went evil such an event would be detected.
      - satai 10y ago
        Please read it more carefuly: "One of the problems with digital certificate management is that fraudulent certificates take a long time to be spotted, reported and revoked by the browser vendors. Certificate Transparency would help by making it impossible for a certificate to be issued for a domain without the domain owner knowing."
- amalag 10y ago
  The main issue I see is ease of MITM for corporate environments. In a corporate environment a trusted root is installed, then an appliance can intercept all SSL certs and re-create the trust chain to introduce their own trusted root so they can read all SSL traffic and your browser says "SECURE". That is broken IMO.
  - asdfasdfasdfa12 10y ago
    This. Thank you for constructing the words I could not.
  - zokier 10y ago
    It is very difficult, if not impossible, to protect against attackers who are in a position where they are able to install their root cert to your browser. If they can do that, then they can do a lot more also. At least in the current system such tampering is generally easily detectable.
  - closeparen 10y ago
    It's broken that device owners can make them behave according to their intentions? Shall we eliminate software freedom too? Otherwise companies can just install a fork of Firefox/Chrome with MITM support added back in to their managed endpoints.
  - roywiggins 10y ago
    Are there any conceivable architectures where whoever owns the computer couldn't MITM themselves? If only for debugging purposes, which would immediately be used by corporate IT for the usual purpose.
- __jal 10y ago
  As I see it, there are a number of issues that need to be cleared up before certs are anything more than snake-oil. Unfortunately, the economics of the current market-reality fight (tooth and nail) against doing so. (Note that I'm limiting this to browser certificate handling.) - We need clients to authenticate servers as well as the reverse. - Browsers need to allow better user control over certificates. I know the reasons why this isn't provided, and I don't care. Add a "reset to defaults" if you're worried about people breaking their browsers, but a sensible way for users to control whom they trust is important. See next point. - As of now, we have a pile of registries with near-zero public view into the operations of people with whom we're literally entrusting our bank accounts. Some of these are overtly in the control of nation-states, and many more are assumed to be at least covertly "assisting". Those of us with a problem with that (which should be everyone - even if you trust your friendly neighborhood intelligence agency, what about all the others?) need much better visibility into the operations of the CAs. I'd argue that they shouldn't even be for-profit operations, but that's not a huge point to me - the important points are knowing which ones are incompetent or compromised by their masters (which are the same thing in once sense, not not in others), and there are various paths to get there. To the browser apologists: is a balkanized web worse than one that cannot be trusted? And are your actions actively harming people by making them believe it is trustworthy when it is not?
  - icebraining 10y ago
    Not an apologist, but a Devil's advocate: Being trustworthy means fulfilling the expectations of the party that is reliant on us, and which are based on what we promise. Currently, the CA system promises very little, with the general idea being that your data is safe from thieves and scammers; certainly not that your communications are safe from law enforcement. Therefore, they are mostly trustworthy. If you start telling people that you can say which CAs are free from interference from intelligence agencies and other top-level snoopers, you're making a much stronger promise, and therefore any flaws in your assessment are much more dangerous.
- zeveb 10y ago
  > The certificates are OK. No, the certificates are pretty terrible too. Take a look at Peter Gutmann's presentations, or read the SPKI RFCs. Among other things, certificates conflate identification, authentication & authorisation; they are based on a flawed, centralised, global phone book model; they are ASN.1; in one case, I believe that the meaning of a single flag has been inverted because of a mistake in a (Microsoft?) library that everyone has had to be bug-compatible with. Some folks think that XPKI is so broken precisely in order to discourage its use (others claim the same thing about IPsec). I don't actually think that's true, but sometimes when I'm banging my head against some stupidity in XPKI, I wonder. I really do.

satai 10y ago

The certificates are OK. The issue is the way they are signed and distributed. Lots of issues with the current PK infrastructure is limited by the certificate transparency.

lclarkmichalek 10y ago
The certificates have their own, independent problems (who thinks x509 is a good format?)
- sitkack 10y ago
  The NSA
asdfasdfasdfa12 10y ago
it is too hard for me to believe that root ca's have not been compromised when anyone working at these companies could likely easily take it without anyone noticing. I do not think transparency has anything at all to do with it. I think an encryption solutions that cannot be 'broken' for decryption is far more required than one that has the 'good guy' in mind. I do not find it an acceptable solution for critical data.
- satai 10y ago
  Not any transparency. Certificate transparency. https://en.m.wikipedia.org/wiki/Certificate_Transparency https://en.m.wikipedia.org/wiki/Certificate_Transparency
  - asdfasdfasdfa12 10y ago
    I think we are talking on different lines of thought. I am not concerned with certificate transparency... as the article you point out says it can take a long time [years] before it is found to be compromised. the fact of the matter is, if ssl decryption is possible on the fly, we need a different solution for encryption, this include the use of credit card chip. an encryption scheme cannot be designed to be broken and expect everything to be 'secure' EDIT: I am not being allowed to reply. excuse me, I think you need to read what I wrote more carefully. I do not care about certificate transparency. I must not be communicating clearly I will try again.. I am not referring to the ability to issue a new certificate. I'm talking about the ability to perform SSL decryption without the end user knowing. you do not need to issue a new certificate to do this, you just need the end user to have trusted a new root CA... which brings us to this article where another company is issuing a root CA. do you trust everyone in your 'trusted root ca's on your computer? Here are some ways to untrust certs [0][1]and another conversation on this [2] [0]http://unix.stackexchange.com/questions/285784/untrusting-an-intermediate-ca-in-linux http://unix.stackexchange.com/questions/285784/untrusting-an... [1] https://blog.filippo.io/untrusting-an-intermediate-ca-on-os-x/ https://blog.filippo.io/untrusting-an-intermediate-ca-on-os-... [2] https://news.ycombinator.com/item?id=11781915 https://news.ycombinator.com/item?id=11781915
    - satai 10y ago
      You can pretty much trust all the root CAs that provide Certificate Transparency. If such a CA went evil such an event would be detected.
    - satai 10y ago
      Please read it more carefuly: "One of the problems with digital certificate management is that fraudulent certificates take a long time to be spotted, reported and revoked by the browser vendors. Certificate Transparency would help by making it impossible for a certificate to be issued for a domain without the domain owner knowing."
amalag 10y ago
The main issue I see is ease of MITM for corporate environments. In a corporate environment a trusted root is installed, then an appliance can intercept all SSL certs and re-create the trust chain to introduce their own trusted root so they can read all SSL traffic and your browser says "SECURE". That is broken IMO.
- asdfasdfasdfa12 10y ago
  This. Thank you for constructing the words I could not.
- zokier 10y ago
  It is very difficult, if not impossible, to protect against attackers who are in a position where they are able to install their root cert to your browser. If they can do that, then they can do a lot more also. At least in the current system such tampering is generally easily detectable.
- closeparen 10y ago
  It's broken that device owners can make them behave according to their intentions? Shall we eliminate software freedom too? Otherwise companies can just install a fork of Firefox/Chrome with MITM support added back in to their managed endpoints.
- roywiggins 10y ago
  Are there any conceivable architectures where whoever owns the computer couldn't MITM themselves? If only for debugging purposes, which would immediately be used by corporate IT for the usual purpose.
__jal 10y ago
As I see it, there are a number of issues that need to be cleared up before certs are anything more than snake-oil. Unfortunately, the economics of the current market-reality fight (tooth and nail) against doing so. (Note that I'm limiting this to browser certificate handling.) - We need clients to authenticate servers as well as the reverse. - Browsers need to allow better user control over certificates. I know the reasons why this isn't provided, and I don't care. Add a "reset to defaults" if you're worried about people breaking their browsers, but a sensible way for users to control whom they trust is important. See next point. - As of now, we have a pile of registries with near-zero public view into the operations of people with whom we're literally entrusting our bank accounts. Some of these are overtly in the control of nation-states, and many more are assumed to be at least covertly "assisting". Those of us with a problem with that (which should be everyone - even if you trust your friendly neighborhood intelligence agency, what about all the others?) need much better visibility into the operations of the CAs. I'd argue that they shouldn't even be for-profit operations, but that's not a huge point to me - the important points are knowing which ones are incompetent or compromised by their masters (which are the same thing in once sense, not not in others), and there are various paths to get there. To the browser apologists: is a balkanized web worse than one that cannot be trusted? And are your actions actively harming people by making them believe it is trustworthy when it is not?
- icebraining 10y ago
  Not an apologist, but a Devil's advocate: Being trustworthy means fulfilling the expectations of the party that is reliant on us, and which are based on what we promise. Currently, the CA system promises very little, with the general idea being that your data is safe from thieves and scammers; certainly not that your communications are safe from law enforcement. Therefore, they are mostly trustworthy. If you start telling people that you can say which CAs are free from interference from intelligence agencies and other top-level snoopers, you're making a much stronger promise, and therefore any flaws in your assessment are much more dangerous.
zeveb 10y ago
> The certificates are OK. No, the certificates are pretty terrible too. Take a look at Peter Gutmann's presentations, or read the SPKI RFCs. Among other things, certificates conflate identification, authentication & authorisation; they are based on a flawed, centralised, global phone book model; they are ASN.1; in one case, I believe that the meaning of a single flag has been inverted because of a mistake in a (Microsoft?) library that everyone has had to be bug-compatible with. Some folks think that XPKI is so broken precisely in order to discourage its use (others claim the same thing about IPsec). I don't actually think that's true, but sometimes when I'm banging my head against some stupidity in XPKI, I wonder. I really do.