6 ms·

No - the point is that if your CA allows an HTTP-01 challenge for certificate issuance, then anyone who can hijack the IP addresses (to which your DNS points) w

No - the point is that if your CA allows an HTTP-01 challenge for certificate issuance, then anyone who can hijack the IP addresses (to which your DNS points) with a BGP attack can subvert that CA to issue their own TLS certificates and subsequently impersonate your service.

egberts1 5y ago
Of which all that could have been averted by having another TLS public/private key issued but this time by the client side and it’s public key then given to the website , no? But who does that nowadays? I still do for my mutual TLS APIs. It’s only if the client public key (which is stored only in the web server could ALSO get hijack then all that would be … for naught (to the hacker’s gain, that is).
- NovemberWhiskey 5y ago
  Mutual TLS doesn't help here - the server TLS implementation can easily be configured to accept any certificate. Mutual TLS gives you mutual authentication, but if the server doesn't care whether the client is authentic or not (because it's been replaced by a malicious implementation) then how does that help?
  - egberts1 5y ago
    .., if the server doesn’t , which is nearly all web browsers today. Not necessarily a properly configured Mutual-TLS non-browser API handler, but the article is talking about what most people use which is a web browser.
    - NovemberWhiskey 5y ago
      I don't really understand what you're describing here: which part of the following do you disagree with? TLS permits client (initiator of the session) and server (target of the session) to have certificates. The purpose of the client certificate is that the server may authenticate the client. The purpose of the server certificate is that the client may authenticate the server. Hence: mutual authentication. If the server is replaced by a malicious implementation that has the private key associated with a genuine certificate, the client will validate the server as authentic. This happens first in the TLS handshake. The malicious server will then happily receive the client certificate and accept it without any chain validation, because it doesn't really care whether the client is authentic or not. To repeat the point: the use of client certificates does not and cannot protect the client.
      - egberts1 5y ago
        If you own both the TLS endpoints, you can keep both keys and any attempt to intercept against the two different set of public keys will fail unless both and only both private keys are compromised. But that defense would only stand by requiring a prior imprint of TLS signatures at both endpoints which no web browser would be able to do during a mutual TLS unless that web browser also starts to takes not only the mutual-thingie client TLS cert but to remember the TLS server public key cert as well beforehanded; not a pretty easy thing to set up by an average web user if the web browser choose to support this. But you can do this strong protection of dual public key exchange for your own set of endpoints and no BGP hijack can get to it unless both-side’s private keys are compromised; it is just that web browser cannot bother with the prior fingerprinting of TLS server due to a variety of reasons (namely expiration, revocation, domain churn, …). This new big data collection of TLS server certa surely can only be rudimentary protection and certainly not against a timing attack, no? My assertion now is that it is the current design of the TLS handling by web browsers is purposely crippled for ease of use purposes. TLS protocol, however, remains robust against such a MitM at IP reroute-level if verification of TLS certs are done both ways and on BOTH sides; kinda like IPSec, right?
        NovemberWhiskey 5y ago
        If you're requiring your client to expect a particular certificate, e.g. certificate pinning, then obviously you don't have this problem. You're also then not participating meaningfully in the internet PKI. You can just self-sign your root and be your own CA. You also don't need mTLS in that case - the two concepts are orthogonal. This is fine in a closed ecosystem, where you can also compel your trust roots into the clients and have a mechanism where you can push out updates to endpoint/public key mappings. This is why you still see HPKP for mobile apps. If DANE were actually a thing then it would also be an option for more open internet use cases; but the reality is that it too comes with its own security and operational problems, and essentially no TLS implementation support as a result of the chicken-and-egg problem. In any case, this is all outside of TLS, which only generally assumes PKIX.
        5y ago
nilsbunger 5y ago
Isn’t it sufficient if any CA allows the HTTP-01 challenge for your domain?
- detaro 5y ago
  Depends if you've locked in a CA with a CAA record or not. If not, then yes, any CA that can be fooled is enough.
  - mittalprat 5y ago
    Having a CAA record and pointing to a CA like Let's Encrypt that uses domain validation from multiple vantage points on the Internet is a useful idea and raises the bar for an adversary. I should point out that BGP attacks can also target the CAA records themselves since the DNS ecosystem is itself insecure. This is why such attacks are not easy to defend against, and require holistic improvements across internet routing, PKI, and web security practices.....
    - egberts1 5y ago
      It is only because the web browsers are still not doing DNSSEC-only query and validation, CAA can easily be spoofed right there. To avert a DNSSEC-secured DNS CAA record from being tampered under BGP hijack, both endpoints must deploy their own cacheless DNSSEC authoritative-only resolvers before commencing mTLS endpoint communication. (Like a web browser would even do that /s). This places the trust of DNSSEC to right at the 13 DNS Root Servers whose private key are stored in a HSM key vault. So, hijacking a DNS infrastructure to tamper the CAA record is only possible because 1) web browser don’t bother with DNSSEC 2) domain owner don’t bother with DNSSEC protection. But even with insecure DNS, I assert that a properly designed REST/HTTPS/“mTLS” API (but would then be totally unusable by web browsers) would still not be intercepted under BGP hijack scenario so that is still an option for any B2B scenario.

egberts1 5y ago

Of which all that could have been averted by having another TLS public/private key issued but this time by the client side and it’s public key then given to the website , no? But who does that nowadays? I still do for my mutual TLS APIs. It’s only if the client public key (which is stored only in the web server could ALSO get hijack then all that would be … for naught (to the hacker’s gain, that is).

NovemberWhiskey 5y ago
Mutual TLS doesn't help here - the server TLS implementation can easily be configured to accept any certificate. Mutual TLS gives you mutual authentication, but if the server doesn't care whether the client is authentic or not (because it's been replaced by a malicious implementation) then how does that help?
- egberts1 5y ago
  .., if the server doesn’t , which is nearly all web browsers today. Not necessarily a properly configured Mutual-TLS non-browser API handler, but the article is talking about what most people use which is a web browser.
  - NovemberWhiskey 5y ago
    I don't really understand what you're describing here: which part of the following do you disagree with? TLS permits client (initiator of the session) and server (target of the session) to have certificates. The purpose of the client certificate is that the server may authenticate the client. The purpose of the server certificate is that the client may authenticate the server. Hence: mutual authentication. If the server is replaced by a malicious implementation that has the private key associated with a genuine certificate, the client will validate the server as authentic. This happens first in the TLS handshake. The malicious server will then happily receive the client certificate and accept it without any chain validation, because it doesn't really care whether the client is authentic or not. To repeat the point: the use of client certificates does not and cannot protect the client.
    - egberts1 5y ago
      If you own both the TLS endpoints, you can keep both keys and any attempt to intercept against the two different set of public keys will fail unless both and only both private keys are compromised. But that defense would only stand by requiring a prior imprint of TLS signatures at both endpoints which no web browser would be able to do during a mutual TLS unless that web browser also starts to takes not only the mutual-thingie client TLS cert but to remember the TLS server public key cert as well beforehanded; not a pretty easy thing to set up by an average web user if the web browser choose to support this. But you can do this strong protection of dual public key exchange for your own set of endpoints and no BGP hijack can get to it unless both-side’s private keys are compromised; it is just that web browser cannot bother with the prior fingerprinting of TLS server due to a variety of reasons (namely expiration, revocation, domain churn, …). This new big data collection of TLS server certa surely can only be rudimentary protection and certainly not against a timing attack, no? My assertion now is that it is the current design of the TLS handling by web browsers is purposely crippled for ease of use purposes. TLS protocol, however, remains robust against such a MitM at IP reroute-level if verification of TLS certs are done both ways and on BOTH sides; kinda like IPSec, right?
      - NovemberWhiskey 5y ago
        If you're requiring your client to expect a particular certificate, e.g. certificate pinning, then obviously you don't have this problem. You're also then not participating meaningfully in the internet PKI. You can just self-sign your root and be your own CA. You also don't need mTLS in that case - the two concepts are orthogonal. This is fine in a closed ecosystem, where you can also compel your trust roots into the clients and have a mechanism where you can push out updates to endpoint/public key mappings. This is why you still see HPKP for mobile apps. If DANE were actually a thing then it would also be an option for more open internet use cases; but the reality is that it too comes with its own security and operational problems, and essentially no TLS implementation support as a result of the chicken-and-egg problem. In any case, this is all outside of TLS, which only generally assumes PKIX.
        5y ago

nilsbunger 5y ago

Isn’t it sufficient if any CA allows the HTTP-01 challenge for your domain?

detaro 5y ago
Depends if you've locked in a CA with a CAA record or not. If not, then yes, any CA that can be fooled is enough.
- mittalprat 5y ago
  Having a CAA record and pointing to a CA like Let's Encrypt that uses domain validation from multiple vantage points on the Internet is a useful idea and raises the bar for an adversary. I should point out that BGP attacks can also target the CAA records themselves since the DNS ecosystem is itself insecure. This is why such attacks are not easy to defend against, and require holistic improvements across internet routing, PKI, and web security practices.....
  - egberts1 5y ago
    It is only because the web browsers are still not doing DNSSEC-only query and validation, CAA can easily be spoofed right there. To avert a DNSSEC-secured DNS CAA record from being tampered under BGP hijack, both endpoints must deploy their own cacheless DNSSEC authoritative-only resolvers before commencing mTLS endpoint communication. (Like a web browser would even do that /s). This places the trust of DNSSEC to right at the 13 DNS Root Servers whose private key are stored in a HSM key vault. So, hijacking a DNS infrastructure to tamper the CAA record is only possible because 1) web browser don’t bother with DNSSEC 2) domain owner don’t bother with DNSSEC protection. But even with insecure DNS, I assert that a properly designed REST/HTTPS/“mTLS” API (but would then be totally unusable by web browsers) would still not be intercepted under BGP hijack scenario so that is still an option for any B2B scenario.