7 ms·

Great write-up - the tip of the iceberg on how fragile TLS/SSL is. Let's add a few: 1. WHOIS isn't encrypted or signed, but is somehow suitable for verificati

Great write-up - the tip of the iceberg on how fragile TLS/SSL is. Let's add a few: 1. WHOIS isn't encrypted or signed, but is somehow suitable for verification (?) 2. DNS CAA records aren't protected by DNSSEC, as absence of a DNS record isn't sign-able (correction: NSEC is an optional DNSSEC extension) 3. DNS root & TLD servers are poorly protected against BGP hijacks (adding that DNSSEC is optional for CAs to verify) 4. Email, used for verification in this post, is also poorly protected against BGP hijacks. I'm amazed we've lasted this long. It must be because if anyone abuses these issues, someone might wake up and care enough to fix them (:

8organicbits 2y ago
> 2. DNS CAA records aren't protected by DNSSEC, as absence of a DNS record isn't sign-able. NSEC does this. > An NSEC record can be used to say: “there are no subdomains between subdomains X and subdomain Y.
- iscoelho 2y ago
  You're correct - noting that Lets Encrypt supports DNSSEC/NSEC fully. Unfortunately though, the entire PKI ecosystem is tainted if other CAs do not share the same security posture.
  - 8organicbits 2y ago
    Tainted seems a little strong, but I think you're right, there's nothing in the CAB Baseline Requirements [1] that requires DNSSEC use by CAs. I wouldn't push for DNSSEC to be required, though, as it's been so sparsely adopted. Any security benefit would be marginal. Second level domain usage has been decreasing (both in percentage and absolute number) since min-2023 [2]. We need to look past DNSSEC. [1] https://cabforum.org/working-groups/server/baseline-requirements/documents/CA-Browser-Forum-TLS-BR-2.0.7.pdf https://cabforum.org/working-groups/server/baseline-requirem... [2] https://www.verisign.com/en_US/company-information/verisign-labs/internet-security-tools/dnssec-scoreboard/index.xhtml https://www.verisign.com/en_US/company-information/verisign-...
    - iscoelho 2y ago
      I agree that DNSSEC is not the answer and has not lived up to expectations whatsoever, but what else is there to verify ownership of a domain? Email- broken. WHOIS- broken. Let's convince all registrars to implement a new standard? ouch.
      - 8organicbits 2y ago
        I'm a fan of the existing standards for DNS (§3.2.2.4.7) and IP address (§3.2.2.4.8) verification. These use multiple network perspectives as a way of reducing risk of network-level attacks. Paired with certificate transparency (and monitoring services). It's not perfect, but that isn't the goal.
        iscoelho 2y ago
        BGP hijacks unfortunately completely destroy that. RPKI is still extremely immature (despite what companies say) and it is still trivial to BGP hijack if you know what you're doing. If you are able to announce a more specific prefix (highly likely unless the target has a strong security competency and their own network), you will receive 100% of the traffic. At that point, it doesn't matter how many vantage points you verify from: all traffic goes to your hijack. It only takes a few seconds for you to verify a certificate, and then you can drop your BGP hijack and pretend nothing happened. Thankfully there are initiatives to detect and alert BGP hijacks, but again, if your organization does not have a strong security competency, you have no knowledge to prevent nor even know about these attacks.
detourdog 2y ago
For reasons not important hear I purchase my SSL certificates and barely have any legitimating business documents. If Dunn & Bradstreet calls I hang up... It took me 3 years of getting SSL certs from the same company through a convoluted process before I tried a different company. My domain has been with the same registrar since private citizens could register DNS names. That relationship meant nothing when trying to prove that I'm me and I own the domain name. I went back to the original company because I could verify myself through their process. My only point is that human relationships is the best form of verifying integrity. I think this provides everyone the opportunity to gain trust and the ability to prejudge people based on association alone.
- lobsterthief 2y ago
  Human relationships also open you up to social engineering attacks. Unless they’re face-to-face, in person, with someone who remembers what you actually look like. Which is rare these days.
  - detourdog 2y ago
    That is my point. We need to put value on the face to face relationships and extend trust outward from our personal relationships. This sort of trust is only as strong as it's weakest link but each individual can choose how far to extend their own trust.
    - dopylitty 2y ago
      This is such a good point. We rely way too much on technical solutions. A better approach is to have hyperlocal offices where you can go to do business. Is this less “efficient”? Yes but when the proceeds of efficiency go to shareholders anyway it doesn’t really matter.
      - mrguyorama 2y ago
        >Is this less “efficient”? Yes but when the proceeds of efficiency go to shareholders anyway it doesn’t really matter. I agree with this but that means you need to regulate it. Even banks nowadays are purposely understaffing themselves and closing early because "what the heck are you going to do about it? Go to a different bank? They're closed at 4pm too!"
candiddevmike 2y ago
Our industry needs to finish what it starts. Between IPv6, DNSSEC, SMTP TLS, SCTP/QUIC, etc all of these bedrock technologies feel like they're permanently stuck in a half completed implementation/migration. Like someone at your work had all these great ideas, started implementing them, then quit when they realized it would be too difficult to complete.
- iscoelho 2y ago
  obligatory https://xkcd.com/927/ https://xkcd.com/927/ Honestly: we're in this situation because we keep trying to band-aid solutions onto ancient protocols that were never designed to be secure. (I'm talking about you DNS.) Given xkcd's wisdom though, I'm not sure if this is easily solvable.
  - sulandor 2y ago
    dns should not have to be secure, it should be regulated as a public utility with 3rd-party quality control and all the whistles. only then can it be trustworthy, fast and free/accessible
    - iscoelho 2y ago
      If my DNS can be MITM'd, and is thus insecure, it is not trustworthy.
      - 8organicbits 2y ago
        This sort of all-or-nothing thinking isn't helpful. DNS points you to a server, TLS certificates help you trust that you've arrived at the right place. It's not perfect, but we build very trustworthy systems on this foundation.
        quesera 2y ago
        But DNS is all-or-nothing. If you can't trust DNS, you can't trust TLS or anything downstream of it. Even banks are not bothering with EV certificates any more, since browsers removed the indicator (for probably-good reasons). DV certificate issuance depends on trustworthy DNS. Internet security is "good enough" for consumers, most of the time. That's "adequately trustworthy", but it's not "very trustworthy".
jrochkind1 2y ago
> It must be because if anyone abuses these issues, someone might wake up and care enough to fix them If anyone knows they are being abused, anyway. I conclude that someone may be abusing them, but those doing so try to keep it unknown that they have done so, to preserve their access to the vulnerability.
- ChrisMarshallNY 2y ago
  Didn't Jon Postel do something like this, once? It was long ago, and I don't remember the details, but I do remember a lot of people having shit hemorrhages.
- iscoelho 2y ago
  Certificate Transparency exists to catch abuse like this. [1] Additionally, Google has pinned their certificates in Chrome and will alert via Certificate Transparency if unexpected certificates are found. [2] It is unlikely this has been abused without anyone noticing. With that said, it definitely can be, there is a window of time before it is noticed to cause damage, and there would be fallout and a "call to action" afterwards as a result. If only someone said something. [1] https://certificate.transparency.dev https://certificate.transparency.dev [2] https://github.com/chromium/chromium/blob/master/net/http/transport_security_state_static.json https://github.com/chromium/chromium/blob/master/net/http/tr...
- hinkley 2y ago
  It’s like the crime numbers. If you’re good enough at embezzling nobody knows you embezzled. So what’s the real crime numbers? Nobody knows. And anyone who has an informed guess isn’t saying. A big company might discover millions are missing years after the fact and back date reports. But nobody is ever going to record those office supplies.
NovemberWhiskey 2y ago
None of these relate to TLS/SSL - that's the wrong level of abstraction: they relate to fragility of the roots of trust on which the registration authorities for Internet PKI depend.
- iscoelho 2y ago
  As long as TLS/SSL depends on Internet PKI as it is, it is flawed. I guess there's always Private PKI, but that's if you're not interested in the internet (^:
  - NovemberWhiskey 2y ago
    I would say that TLS/SSL doesn't depend on Internet PKI - browsers (etc) depend on Internet PKI in combination with TLS/SSL.
  - tialaramex 2y ago
    TLS doesn't care what's in the certificate even if you use certificate authentication (which you don't have to for either side). Photo of your 10 metre swimming certificate awarded when you were seven? Fine. MP3 of your cat "singing along" with a pop song? Also fine. Now, the application using TLS probably cares, and most Internet applications want an X.509 certificate, conforming more or less with PKIX and typically from the Web PKI. But TLS doesn't care about those details.
account42 2y ago
> 1. WHOIS isn't encrypted or signed, but is somehow suitable for verification (?) HTTP-based ACME verification also uses unencrypted port-80 HTTP. Similar for DNS-based verification.
- iscoelho 2y ago
  100% - another for the BGP hijack!
  - michaelt 2y ago
    The current CAB Forum Baseline Requirements call for "Multi-Perspective Issuance Corroboration" [1] i.e. make sure the DNS or HTTP challenge looks the same from several different data centres in different countries. By the end of 2026, CAs will validate from 5 different data centres. This should make getting a cert via BGP hijack very difficult. [1] https://github.com/cabforum/servercert/blob/main/docs/BR.md#3229-multi-perspective-issuance-corroboration https://github.com/cabforum/servercert/blob/main/docs/BR.md#...
    - tialaramex 2y ago
      It is hypothesised to make this more difficult but it's unclear how effective it is in practice. I wouldn't expect it to make a significant difference. We've been here before.
    - iscoelho 2y ago
      See my post above about BGP hijacks: https://news.ycombinator.com/item?id=41511582 https://news.ycombinator.com/item?id=41511582 - They're way easier than you think.
- bootsmann 2y ago
  > HTTP-based ACME verification also uses unencrypted port-80 HTTP I mean, they need to bootstrap the verification somehow no? You cannot upgrade the first time you request a challenge.
- Arch-TK 2y ago
graemep 2y ago
Its used for verification because its cheap, not because its good. Why would you expect anyone to care enough to fix it. If we really wanted verification we would still be manually verifying the owners of domains. Highly effective but expensive.
deleted 2y ago
[deleted]
codethief 2y ago
> 4. Email, used for verification in this post, is also poorly protected against BGP hijacks. Do mail servers even verify TLS certs these days instead of just ignoring them?

8organicbits 2y ago

> 2. DNS CAA records aren't protected by DNSSEC, as absence of a DNS record isn't sign-able. NSEC does this. > An NSEC record can be used to say: “there are no subdomains between subdomains X and subdomain Y.

iscoelho 2y ago
You're correct - noting that Lets Encrypt supports DNSSEC/NSEC fully. Unfortunately though, the entire PKI ecosystem is tainted if other CAs do not share the same security posture.
- 8organicbits 2y ago
  Tainted seems a little strong, but I think you're right, there's nothing in the CAB Baseline Requirements [1] that requires DNSSEC use by CAs. I wouldn't push for DNSSEC to be required, though, as it's been so sparsely adopted. Any security benefit would be marginal. Second level domain usage has been decreasing (both in percentage and absolute number) since min-2023 [2]. We need to look past DNSSEC. [1] https://cabforum.org/working-groups/server/baseline-requirements/documents/CA-Browser-Forum-TLS-BR-2.0.7.pdf https://cabforum.org/working-groups/server/baseline-requirem... [2] https://www.verisign.com/en_US/company-information/verisign-labs/internet-security-tools/dnssec-scoreboard/index.xhtml https://www.verisign.com/en_US/company-information/verisign-...
  - iscoelho 2y ago
    I agree that DNSSEC is not the answer and has not lived up to expectations whatsoever, but what else is there to verify ownership of a domain? Email- broken. WHOIS- broken. Let's convince all registrars to implement a new standard? ouch.
    - 8organicbits 2y ago
      I'm a fan of the existing standards for DNS (§3.2.2.4.7) and IP address (§3.2.2.4.8) verification. These use multiple network perspectives as a way of reducing risk of network-level attacks. Paired with certificate transparency (and monitoring services). It's not perfect, but that isn't the goal.
      - iscoelho 2y ago
        BGP hijacks unfortunately completely destroy that. RPKI is still extremely immature (despite what companies say) and it is still trivial to BGP hijack if you know what you're doing. If you are able to announce a more specific prefix (highly likely unless the target has a strong security competency and their own network), you will receive 100% of the traffic. At that point, it doesn't matter how many vantage points you verify from: all traffic goes to your hijack. It only takes a few seconds for you to verify a certificate, and then you can drop your BGP hijack and pretend nothing happened. Thankfully there are initiatives to detect and alert BGP hijacks, but again, if your organization does not have a strong security competency, you have no knowledge to prevent nor even know about these attacks.

detourdog 2y ago

For reasons not important hear I purchase my SSL certificates and barely have any legitimating business documents. If Dunn & Bradstreet calls I hang up... It took me 3 years of getting SSL certs from the same company through a convoluted process before I tried a different company. My domain has been with the same registrar since private citizens could register DNS names. That relationship meant nothing when trying to prove that I'm me and I own the domain name. I went back to the original company because I could verify myself through their process. My only point is that human relationships is the best form of verifying integrity. I think this provides everyone the opportunity to gain trust and the ability to prejudge people based on association alone.

lobsterthief 2y ago
Human relationships also open you up to social engineering attacks. Unless they’re face-to-face, in person, with someone who remembers what you actually look like. Which is rare these days.
- detourdog 2y ago
  That is my point. We need to put value on the face to face relationships and extend trust outward from our personal relationships. This sort of trust is only as strong as it's weakest link but each individual can choose how far to extend their own trust.
  - dopylitty 2y ago
    This is such a good point. We rely way too much on technical solutions. A better approach is to have hyperlocal offices where you can go to do business. Is this less “efficient”? Yes but when the proceeds of efficiency go to shareholders anyway it doesn’t really matter.
    - mrguyorama 2y ago
      >Is this less “efficient”? Yes but when the proceeds of efficiency go to shareholders anyway it doesn’t really matter. I agree with this but that means you need to regulate it. Even banks nowadays are purposely understaffing themselves and closing early because "what the heck are you going to do about it? Go to a different bank? They're closed at 4pm too!"

candiddevmike 2y ago

Our industry needs to finish what it starts. Between IPv6, DNSSEC, SMTP TLS, SCTP/QUIC, etc all of these bedrock technologies feel like they're permanently stuck in a half completed implementation/migration. Like someone at your work had all these great ideas, started implementing them, then quit when they realized it would be too difficult to complete.

iscoelho 2y ago
obligatory https://xkcd.com/927/ https://xkcd.com/927/ Honestly: we're in this situation because we keep trying to band-aid solutions onto ancient protocols that were never designed to be secure. (I'm talking about you DNS.) Given xkcd's wisdom though, I'm not sure if this is easily solvable.
- sulandor 2y ago
  dns should not have to be secure, it should be regulated as a public utility with 3rd-party quality control and all the whistles. only then can it be trustworthy, fast and free/accessible
  - iscoelho 2y ago
    If my DNS can be MITM'd, and is thus insecure, it is not trustworthy.
    - 8organicbits 2y ago
      This sort of all-or-nothing thinking isn't helpful. DNS points you to a server, TLS certificates help you trust that you've arrived at the right place. It's not perfect, but we build very trustworthy systems on this foundation.
      - quesera 2y ago
        But DNS is all-or-nothing. If you can't trust DNS, you can't trust TLS or anything downstream of it. Even banks are not bothering with EV certificates any more, since browsers removed the indicator (for probably-good reasons). DV certificate issuance depends on trustworthy DNS. Internet security is "good enough" for consumers, most of the time. That's "adequately trustworthy", but it's not "very trustworthy".

jrochkind1 2y ago

> It must be because if anyone abuses these issues, someone might wake up and care enough to fix them If anyone knows they are being abused, anyway. I conclude that someone may be abusing them, but those doing so try to keep it unknown that they have done so, to preserve their access to the vulnerability.

ChrisMarshallNY 2y ago
Didn't Jon Postel do something like this, once? It was long ago, and I don't remember the details, but I do remember a lot of people having shit hemorrhages.
iscoelho 2y ago
Certificate Transparency exists to catch abuse like this. [1] Additionally, Google has pinned their certificates in Chrome and will alert via Certificate Transparency if unexpected certificates are found. [2] It is unlikely this has been abused without anyone noticing. With that said, it definitely can be, there is a window of time before it is noticed to cause damage, and there would be fallout and a "call to action" afterwards as a result. If only someone said something. [1] https://certificate.transparency.dev https://certificate.transparency.dev [2] https://github.com/chromium/chromium/blob/master/net/http/transport_security_state_static.json https://github.com/chromium/chromium/blob/master/net/http/tr...
hinkley 2y ago
It’s like the crime numbers. If you’re good enough at embezzling nobody knows you embezzled. So what’s the real crime numbers? Nobody knows. And anyone who has an informed guess isn’t saying. A big company might discover millions are missing years after the fact and back date reports. But nobody is ever going to record those office supplies.

NovemberWhiskey 2y ago

None of these relate to TLS/SSL - that's the wrong level of abstraction: they relate to fragility of the roots of trust on which the registration authorities for Internet PKI depend.

iscoelho 2y ago
As long as TLS/SSL depends on Internet PKI as it is, it is flawed. I guess there's always Private PKI, but that's if you're not interested in the internet (^:
- NovemberWhiskey 2y ago
  I would say that TLS/SSL doesn't depend on Internet PKI - browsers (etc) depend on Internet PKI in combination with TLS/SSL.
- tialaramex 2y ago
  TLS doesn't care what's in the certificate even if you use certificate authentication (which you don't have to for either side). Photo of your 10 metre swimming certificate awarded when you were seven? Fine. MP3 of your cat "singing along" with a pop song? Also fine. Now, the application using TLS probably cares, and most Internet applications want an X.509 certificate, conforming more or less with PKIX and typically from the Web PKI. But TLS doesn't care about those details.

account42 2y ago

> 1. WHOIS isn't encrypted or signed, but is somehow suitable for verification (?) HTTP-based ACME verification also uses unencrypted port-80 HTTP. Similar for DNS-based verification.

iscoelho 2y ago
100% - another for the BGP hijack!
- michaelt 2y ago
  The current CAB Forum Baseline Requirements call for "Multi-Perspective Issuance Corroboration" [1] i.e. make sure the DNS or HTTP challenge looks the same from several different data centres in different countries. By the end of 2026, CAs will validate from 5 different data centres. This should make getting a cert via BGP hijack very difficult. [1] https://github.com/cabforum/servercert/blob/main/docs/BR.md#3229-multi-perspective-issuance-corroboration https://github.com/cabforum/servercert/blob/main/docs/BR.md#...
  - tialaramex 2y ago
    It is hypothesised to make this more difficult but it's unclear how effective it is in practice. I wouldn't expect it to make a significant difference. We've been here before.
  - iscoelho 2y ago
    See my post above about BGP hijacks: https://news.ycombinator.com/item?id=41511582 https://news.ycombinator.com/item?id=41511582 - They're way easier than you think.
bootsmann 2y ago
> HTTP-based ACME verification also uses unencrypted port-80 HTTP I mean, they need to bootstrap the verification somehow no? You cannot upgrade the first time you request a challenge.
Arch-TK 2y ago

graemep 2y ago

Its used for verification because its cheap, not because its good. Why would you expect anyone to care enough to fix it. If we really wanted verification we would still be manually verifying the owners of domains. Highly effective but expensive.

deleted 2y ago

[deleted]

codethief 2y ago

> 4. Email, used for verification in this post, is also poorly protected against BGP hijacks. Do mail servers even verify TLS certs these days instead of just ignoring them?