4 ms·

This is one of the reasons TLS/SSL and crypto is so amazingly important. Go ahead, monkey around with BGP, since I have the public key of the recipient of my p

by burtonator2011 8y ago

This is one of the reasons TLS/SSL and crypto is so amazingly important. Go ahead, monkey around with BGP, since I have the public key of the recipient of my packets I can detect this and block any type of misdirection.

maltalex 8y ago
> Go ahead, monkey around with BGP, since I have the public key of the recipient of my packets I can detect this and block any type of misdirection. And how did you get that public key? An attacker could pretty easily obtain a valid Let's Encrypt certificate using a BGP hijack. Also, the CA system is in bad shape - CAs have been hacked and certificates were leaked. Not to mention that some of the CAs your browser trusts are not entirely trustworthy or are located in untrustworthy countries. Oh, and from time to time there are attacks against TLS itself (e.g. https://drownattack.com/ https://drownattack.com/)
- dcbadacd 8y ago
  We should definitely talk more about those CAs and should totally have a way to force only certain CAs should be able to give out certs for a domain. Oh wait, it's called HPKP and it's being removed D:
  - jopsen 8y ago
    Expect-Ct anyone? Then we can delist compromised CAs, yay :) (Sure, it'll take time, but gaps seems to be closing on so many layers)
  - olliej 8y ago
    HPKP was a bad standard - there’s no way it could be used safely at scale. There are just too many ways to accidentally screw up, and that’s before you start dealing with actual attackers. CT allows you to detect misissuance - theoretically you could have a monitor service that watched all the logs for changes to your domains. Longer term something (no opinion stated on exactly what) needs to be done to rectify the trust model for BGP and DNS
- 0xb100db1ade 8y ago
  > An attacker could pretty easily obtain a valid Let's Encrypt certificate using a BGP hijack. Whoah, I have never realized this. Is there some way to include some key in the DNS entry or something to mitigate IP hijacking? Does HSTS protect against this?
  - deleted 8y ago
    [deleted]
  - r1ch 8y ago
    Let's Encrypt is already taking steps to mitigate this. BGP hijacking is a noisy event - it should be possible to see that routes have changed recently and deny issuance. They can also perform challenges from multiple geos / networks, so that if there's a disagreement among routes, the challenge fails. More info: https://secure-certificates.princeton.edu/ https://secure-certificates.princeton.edu/
- olliej 8y ago
  Because the public keys are baked into the OS trust store. For the exact reason of not being able to get the keys from the internet if you don’t already have a root of trust. The other issues (trust worthiness of CAs in countries that have the ability to compel a ca to issue a fake cert -Australia say), are intended to be mitigated by the CT logging that is now required by the major trust stores. Sure your Aussie CA might issue a fake certificate, but in doing so they ensure they get a global distrust...
  - cheeze 8y ago
    The dream is definitely not trusting certs which haven't been written to a log. I think that the path is actually in sight too. The CAB forum seems relatively on board.
    - olliej 8y ago
      the CAs are the only ones opposed.
    - tialaramex 8y ago
      You can experience this dream today by simply installing Google's "Chrome" browser. If you prefer a different browser you probably don't have long to wait, Firefox and Safari have announced plans to check CT (Apple says in Calendar Year 2018 but I won't be astonished if that slips) and it's something Microsoft's browser team are contemplating - if you care about trust in the Web PKI you obviously shouldn't use Microsoft's products anyway, but if you do...
    - deleted 8y ago
      [deleted]
  - rocqua 8y ago
    In order for CT to really work, we will need a better way to handle actually distrusting CAs. I think that includes a way for a site to have multiple different certs at the same time, so their one CA isn't a single point of failure. Without this, we will always be dragging our feet in dropping CA trust, because it will leave some perfectly valid sites shit out of luck.

maltalex 8y ago

> Go ahead, monkey around with BGP, since I have the public key of the recipient of my packets I can detect this and block any type of misdirection. And how did you get that public key? An attacker could pretty easily obtain a valid Let's Encrypt certificate using a BGP hijack. Also, the CA system is in bad shape - CAs have been hacked and certificates were leaked. Not to mention that some of the CAs your browser trusts are not entirely trustworthy or are located in untrustworthy countries. Oh, and from time to time there are attacks against TLS itself (e.g. https://drownattack.com/ https://drownattack.com/)

dcbadacd 8y ago
We should definitely talk more about those CAs and should totally have a way to force only certain CAs should be able to give out certs for a domain. Oh wait, it's called HPKP and it's being removed D:
- jopsen 8y ago
  Expect-Ct anyone? Then we can delist compromised CAs, yay :) (Sure, it'll take time, but gaps seems to be closing on so many layers)
- olliej 8y ago
  HPKP was a bad standard - there’s no way it could be used safely at scale. There are just too many ways to accidentally screw up, and that’s before you start dealing with actual attackers. CT allows you to detect misissuance - theoretically you could have a monitor service that watched all the logs for changes to your domains. Longer term something (no opinion stated on exactly what) needs to be done to rectify the trust model for BGP and DNS
0xb100db1ade 8y ago
> An attacker could pretty easily obtain a valid Let's Encrypt certificate using a BGP hijack. Whoah, I have never realized this. Is there some way to include some key in the DNS entry or something to mitigate IP hijacking? Does HSTS protect against this?
- deleted 8y ago
  [deleted]
- r1ch 8y ago
  Let's Encrypt is already taking steps to mitigate this. BGP hijacking is a noisy event - it should be possible to see that routes have changed recently and deny issuance. They can also perform challenges from multiple geos / networks, so that if there's a disagreement among routes, the challenge fails. More info: https://secure-certificates.princeton.edu/ https://secure-certificates.princeton.edu/
olliej 8y ago
Because the public keys are baked into the OS trust store. For the exact reason of not being able to get the keys from the internet if you don’t already have a root of trust. The other issues (trust worthiness of CAs in countries that have the ability to compel a ca to issue a fake cert -Australia say), are intended to be mitigated by the CT logging that is now required by the major trust stores. Sure your Aussie CA might issue a fake certificate, but in doing so they ensure they get a global distrust...
- cheeze 8y ago
  The dream is definitely not trusting certs which haven't been written to a log. I think that the path is actually in sight too. The CAB forum seems relatively on board.
  - olliej 8y ago
    the CAs are the only ones opposed.
  - tialaramex 8y ago
    You can experience this dream today by simply installing Google's "Chrome" browser. If you prefer a different browser you probably don't have long to wait, Firefox and Safari have announced plans to check CT (Apple says in Calendar Year 2018 but I won't be astonished if that slips) and it's something Microsoft's browser team are contemplating - if you care about trust in the Web PKI you obviously shouldn't use Microsoft's products anyway, but if you do...
  - deleted 8y ago
    [deleted]
- rocqua 8y ago
  In order for CT to really work, we will need a better way to handle actually distrusting CAs. I think that includes a way for a site to have multiple different certs at the same time, so their one CA isn't a single point of failure. Without this, we will always be dragging our feet in dropping CA trust, because it will leave some perfectly valid sites shit out of luck.