6 ms·

I agree with most of the mitigation suggestions. For high risk targets, consider layering an additional auth mechanism that doesn't rely on trusted CAs: Tor on

I agree with most of the mitigation suggestions. For high risk targets, consider layering an additional auth mechanism that doesn't rely on trusted CAs: Tor onion services, SSH, or Wireguard. > All issued SSL/TLS certificates are subject to certificate transparency. +1. crt.sh has RSS feeds for this. > Limit validation methods and set exact account identifiers Using CAA is a good idea in general, but would it help in this case? The attacker would just request the exact cert configuration that is permitted by CAA. Maybe this helps if you can strengthen one validation method? > Monitor SSL/TLS certificate changes on all your services using external service +1. High-risk targets should be aware of what certs are valid at any time, and be checking for those. > Monitor MAC address of default gateway for changes A more sophisticated attack could preserve the MAC address. > "Channel binding" is a feature in XMPP which can detect a MiTM even if the interceptor present a valid certificate. TIL.

hlandau 3y ago
>Using CAA is a good idea in general, but would it help in this case? The attacker would just request the exact cert configuration that is permitted by CAA. Maybe this helps if you can strengthen one validation method? Author of ACME-CAA (RFC 8657) here. ACME-CAA can mitigate this because you can put a unique identifier for your ACME account in the CAA record, so it is not possible for an attacker to do this unless they can get your ACME account private key (or coerce the ACME service). This assumes you have DNSSEC-secured nameservers, of course, otherwise DNS requests can potentially also be intercepted when queried by the CA. See RFC 8657 for a full list of security caveats. The RFC is designed to be more readable than most. Blogpost by me with more background: https://www.devever.net/~hl/acme-caa-live https://www.devever.net/~hl/acme-caa-live
- aaomidi 3y ago
  Yep! This is one way of preventing this type of attack.
- crosser 3y ago
  Could you please elaborate the reasons to implement this outside of DANE (RFC-7671) framework?
  - tialaramex 3y ago
    DANE assumes we can successfully deploy this to the entire Internet. It is unclear that's ever possible, and it's certainly not possible today. Lots of things would be great if you can deploy them, for example you wouldn't build QUIC on top of UDP since you can "just" deploy a new transport protocol - except nope, for the foreseeable future that's undeployable. A public CA generally has a more sophisticated relationship with their network transit provider or (hopefully) providers and can get DNSSEC actually working as intended for them. So this means mything.example's DNS services and some public CA both need working DNSSEC, but the visitors to mything.example, such as your mom's sister or some guy who just go into mything but isn't entirely clear whether Apple make Windows - do not need DNSSEc, for them everything works exactly as before, yet the certificate acquisition step is protected from third parties. Would that help? It depends.
  - fanf2 3y ago
    CAA is about preventing certificate mis-issuance, which is what happened in this attack. DNSSEC and CAA could have prevented this attack from being performed the way it was, by thwarting the MITM on ACME. DANE is about changing the way certificates are authenticated. DANE makes it possible to authenticate certificates without getting them issued by a well-known CA. So CAA records are not particularly relevant to DANE. You can use DANE with certificates issued by a CA, which gives you two ways to authenticate the certificate; in this situation CAA secures one path and DANE the other. I am one of the co-authors of the DANE SRV RFC https://www.rfc-editor.org/rfc/rfc7673 https://www.rfc-editor.org/rfc/rfc7673 which is what XMPP would use. I don’t follow XMPP development so I don’t know if it has been deployed. I would like it if DANE were more widely used, but it’s not pertinent to this attack.
    - crosser 3y ago
      Why not? You could use "certificate usage" value 1 and (if the implementation does not neglect it) immediately notice that validation by CA disagrees with validation by DNS. That should be good enough, no?
- hlandau 3y ago
  Small update: I've just written a blogpost with my thoughts on the incident. https://www.devever.net/~hl/xmpp-incident https://www.devever.net/~hl/xmpp-incident I usually brood on blogposts for days before publishing them since I care a lot about getting things accurate, but this is a bit of the moment, so here goes. Always happy to get feedback by email or IRC: https://www.devever.net/~hl/contact https://www.devever.net/~hl/contact
  - ThePowerOfFuet 3y ago
    Is it just me, or would a recurring RIPE Atlas measurement be a great way to detect fuckery like this? https://atlas.ripe.net/ https://atlas.ripe.net/
    - bananapub 3y ago
      not at all, since there were no Internet-visible routing changes. atlas would be good for detecting the time Pakistan announced 0/0 or whatever.
      - karmahunter1234 3y ago
        I think atlas allows tls/ssl probes, so that could still be used to track unexpected changes in certificates?
- 3np 3y ago
  Wuuut, I missed they finally enabled it. Everyone who has infra MitM in their threat-model should look into and enable this. Also, thank you for your work as well as popping in here. Am I overstating it by seeing it as one of the most important milestones for Internet security in general over the past few years? Do you have a take on DLT-based systems and if this is something that is (or could be) seriously discussed? It seems to me that the issues we have with PKI and certificate transparency could actually be mitigated very well if blockchain was seriously considered.
  - hlandau 3y ago
    So I assume DLT is a generic/more general term for blockchain technology. There's this thing called Zooko's triangle (https://en.wikipedia.org/wiki/Zooko%27s_triangle https://en.wikipedia.org/wiki/Zooko%27s_triangle), basically the premise that an identifier can only have two of the following properties: secure, decentralized, human-readable. But a blockchain can actually be used to square this triangle and get all three. The original example of this is the Namecoin project, a fork of Bitcoin using a lightly modified Bitcoin codebase which can be used as a key-value store. The idea is that a blockchain can be used to create a decentralized database mapping keys (domain names) to values (which can be things like IP addresses, but also PKI trust anchors, similar to DANE). Thus this can eliminate the need for a CA. You can also use it to map human-readable names to .onion addresses. There is also root-of-trust transparency built in since the contents of the database is public and any changes are also public. The right to change a key-value entry belongs to the public key of the person who registered that key. Nobody can override this. Namecoin domain names use the .bit (unofficial) TLD. It's a really neat technology and also makes things like censorship via domain suspensions, your registrar getting hacked, etc. infeasible. Full disclosure, I previously worked on the Namecoin project, I authored the DNS resolution daemon and the technical specification for the format of DNS data in the KV store. Unfortunately public interest in the project has waned, and deployment is the real issue - you have to have the client software to be able to resolve these domain names. There is at least some conceivable possibility Tor might ship it in their bundle in the future though, so people could type example.bit in Tor Browser to get to a hidden service. The project remains active though.
- Groxx 3y ago
  Interesting and I can see some of the benefits, particularly in preventing DNS controllers from going to other CAs and making new keys, but... this all seems like a weird run-around for the MITM part. Couldn't you exchange public keys with LetsEncrypt (in the web UI) and encrypt the response so you can't be MITMed? Why is http even an issue?
  - KairuByte 3y ago
    Because the attacker can simply request new keys. There’s nothing stopping them from going “hey LE, I need a new key! This is my domain, here is the challenge, give me my cert!” And LE will oblige, because as far as it can tell, they are you. Edit: To be clear, this is a problem with a solution. But you asked why simply throwing a LE cert into the mix wouldn’t prevent the issue.
    - Groxx 3y ago
      Ownership is already handled by checking DNS (and this thread covers a way to make that even more secure, which LE supports), and as far as I can tell neither has nothing to do with preventing MITM between LE and your servers. And no, I don't mean throwing LE certs around to prevent MITM - this whole article is about the difficulties before having an LE cert, so that's necessarily excluded. I'm wondering "why not client certificates". They're a well established way to stop MITM, seems like a simple choice for the ownership validation step.
      - salawat 3y ago
        Have you ever tried to explain key distribution/management to a normal person? You should try it sometime.
        Groxx 3y ago
        Sure, but this is not particularly relevant when talking about a security product that you use to do key distribution and management (LetsEncrypt). Explaining and guiding people through that is the whole point.
0xbadcafebee 3y ago
> All issued SSL/TLS certificates are subject to certificate transparency. Until the nation state tells a CA within their borders to issue a cert without publishing the CT logs, along with a gag order. If they don't comply they go to jail. You think Billy Bob Sysadmin wants to go to jail to protect a russian jabber server?
- bart__ 3y ago
  Browsers will check if a certificate is in the transparency log, and alert the user if it isn't if I am not mistaken.
  - deleted 3y ago
    [deleted]
  - crtasm 3y ago
    But XMPP clients do not, as far as I'm aware? and browsers aren't connecting to XMPP server ports.
    - est31 3y ago
      Yeah usually the TLS libraries used by XMPP clients don't check SCTs. Not even all browsers do it. Chrome does it, Firefox does not for example.
  - privacyking 3y ago
    Source?
    - bart__ 3y ago
      https://developer.mozilla.org/en-US/docs/Web/Security/Certificate_Transparency#browser_requirements https://developer.mozilla.org/en-US/docs/Web/Security/Certif... As the other commenter already pointed out, Firefox does not require this. Safari and Chrome do. This indeed is not directly applicable to this situation, since XMPP don't involve browsers. But for websites, the parents attack scenario is not applicable.
abigail95 3y ago
If they have physical access to your server, they'll just go for that. With mild difficulty you can mirror the disk, net, and RAM of any "commodity" hardware.
codedokode 3y ago
[flagged]
- lxgr 3y ago
  How would you implement “strict checking” at scale and for free?
  - codedokode 3y ago
    If they used DNS validation it would be better because there would be only one point of failure (DNS) rather than many (DNS and every ISP between CA and a site).
    - Jenda_ 3y ago
      The thread above (https://news.ycombinator.com/item?id=37958831 https://news.ycombinator.com/item?id=37958831) elaborates on how to force DNS validation and/or how to tie your private key with Let's Encrypt via DNS.
      - codedokode 3y ago
        Everyone needs to opt-in to use more secure methods and by default non-secure validation methods, which allow easy issuing fake certificates, are allowed. This is wrong.
        Jenda_ 3y ago
        So, what should they do? No certificate without DNS record? Would this really help the overall state of affairs, or would most sites just not use HTTPS at all because it's "too complicated"?
        codedokode 3y ago
        The purpose of using HTTPS is to make connections more secure. Giving away SSL certificates to anyone does not serve this purpose.

hlandau 3y ago

>Using CAA is a good idea in general, but would it help in this case? The attacker would just request the exact cert configuration that is permitted by CAA. Maybe this helps if you can strengthen one validation method? Author of ACME-CAA (RFC 8657) here. ACME-CAA can mitigate this because you can put a unique identifier for your ACME account in the CAA record, so it is not possible for an attacker to do this unless they can get your ACME account private key (or coerce the ACME service). This assumes you have DNSSEC-secured nameservers, of course, otherwise DNS requests can potentially also be intercepted when queried by the CA. See RFC 8657 for a full list of security caveats. The RFC is designed to be more readable than most. Blogpost by me with more background: https://www.devever.net/~hl/acme-caa-live https://www.devever.net/~hl/acme-caa-live

aaomidi 3y ago
Yep! This is one way of preventing this type of attack.
crosser 3y ago
Could you please elaborate the reasons to implement this outside of DANE (RFC-7671) framework?
- tialaramex 3y ago
  DANE assumes we can successfully deploy this to the entire Internet. It is unclear that's ever possible, and it's certainly not possible today. Lots of things would be great if you can deploy them, for example you wouldn't build QUIC on top of UDP since you can "just" deploy a new transport protocol - except nope, for the foreseeable future that's undeployable. A public CA generally has a more sophisticated relationship with their network transit provider or (hopefully) providers and can get DNSSEC actually working as intended for them. So this means mything.example's DNS services and some public CA both need working DNSSEC, but the visitors to mything.example, such as your mom's sister or some guy who just go into mything but isn't entirely clear whether Apple make Windows - do not need DNSSEc, for them everything works exactly as before, yet the certificate acquisition step is protected from third parties. Would that help? It depends.
- fanf2 3y ago
  CAA is about preventing certificate mis-issuance, which is what happened in this attack. DNSSEC and CAA could have prevented this attack from being performed the way it was, by thwarting the MITM on ACME. DANE is about changing the way certificates are authenticated. DANE makes it possible to authenticate certificates without getting them issued by a well-known CA. So CAA records are not particularly relevant to DANE. You can use DANE with certificates issued by a CA, which gives you two ways to authenticate the certificate; in this situation CAA secures one path and DANE the other. I am one of the co-authors of the DANE SRV RFC https://www.rfc-editor.org/rfc/rfc7673 https://www.rfc-editor.org/rfc/rfc7673 which is what XMPP would use. I don’t follow XMPP development so I don’t know if it has been deployed. I would like it if DANE were more widely used, but it’s not pertinent to this attack.
  - crosser 3y ago
    Why not? You could use "certificate usage" value 1 and (if the implementation does not neglect it) immediately notice that validation by CA disagrees with validation by DNS. That should be good enough, no?
hlandau 3y ago
Small update: I've just written a blogpost with my thoughts on the incident. https://www.devever.net/~hl/xmpp-incident https://www.devever.net/~hl/xmpp-incident I usually brood on blogposts for days before publishing them since I care a lot about getting things accurate, but this is a bit of the moment, so here goes. Always happy to get feedback by email or IRC: https://www.devever.net/~hl/contact https://www.devever.net/~hl/contact
- ThePowerOfFuet 3y ago
  Is it just me, or would a recurring RIPE Atlas measurement be a great way to detect fuckery like this? https://atlas.ripe.net/ https://atlas.ripe.net/
  - bananapub 3y ago
    not at all, since there were no Internet-visible routing changes. atlas would be good for detecting the time Pakistan announced 0/0 or whatever.
    - karmahunter1234 3y ago
      I think atlas allows tls/ssl probes, so that could still be used to track unexpected changes in certificates?
3np 3y ago
Wuuut, I missed they finally enabled it. Everyone who has infra MitM in their threat-model should look into and enable this. Also, thank you for your work as well as popping in here. Am I overstating it by seeing it as one of the most important milestones for Internet security in general over the past few years? Do you have a take on DLT-based systems and if this is something that is (or could be) seriously discussed? It seems to me that the issues we have with PKI and certificate transparency could actually be mitigated very well if blockchain was seriously considered.
- hlandau 3y ago
  So I assume DLT is a generic/more general term for blockchain technology. There's this thing called Zooko's triangle (https://en.wikipedia.org/wiki/Zooko%27s_triangle https://en.wikipedia.org/wiki/Zooko%27s_triangle), basically the premise that an identifier can only have two of the following properties: secure, decentralized, human-readable. But a blockchain can actually be used to square this triangle and get all three. The original example of this is the Namecoin project, a fork of Bitcoin using a lightly modified Bitcoin codebase which can be used as a key-value store. The idea is that a blockchain can be used to create a decentralized database mapping keys (domain names) to values (which can be things like IP addresses, but also PKI trust anchors, similar to DANE). Thus this can eliminate the need for a CA. You can also use it to map human-readable names to .onion addresses. There is also root-of-trust transparency built in since the contents of the database is public and any changes are also public. The right to change a key-value entry belongs to the public key of the person who registered that key. Nobody can override this. Namecoin domain names use the .bit (unofficial) TLD. It's a really neat technology and also makes things like censorship via domain suspensions, your registrar getting hacked, etc. infeasible. Full disclosure, I previously worked on the Namecoin project, I authored the DNS resolution daemon and the technical specification for the format of DNS data in the KV store. Unfortunately public interest in the project has waned, and deployment is the real issue - you have to have the client software to be able to resolve these domain names. There is at least some conceivable possibility Tor might ship it in their bundle in the future though, so people could type example.bit in Tor Browser to get to a hidden service. The project remains active though.
Groxx 3y ago
Interesting and I can see some of the benefits, particularly in preventing DNS controllers from going to other CAs and making new keys, but... this all seems like a weird run-around for the MITM part. Couldn't you exchange public keys with LetsEncrypt (in the web UI) and encrypt the response so you can't be MITMed? Why is http even an issue?
- KairuByte 3y ago
  Because the attacker can simply request new keys. There’s nothing stopping them from going “hey LE, I need a new key! This is my domain, here is the challenge, give me my cert!” And LE will oblige, because as far as it can tell, they are you. Edit: To be clear, this is a problem with a solution. But you asked why simply throwing a LE cert into the mix wouldn’t prevent the issue.
  - Groxx 3y ago
    Ownership is already handled by checking DNS (and this thread covers a way to make that even more secure, which LE supports), and as far as I can tell neither has nothing to do with preventing MITM between LE and your servers. And no, I don't mean throwing LE certs around to prevent MITM - this whole article is about the difficulties before having an LE cert, so that's necessarily excluded. I'm wondering "why not client certificates". They're a well established way to stop MITM, seems like a simple choice for the ownership validation step.
    - salawat 3y ago
      Have you ever tried to explain key distribution/management to a normal person? You should try it sometime.
      - Groxx 3y ago
        Sure, but this is not particularly relevant when talking about a security product that you use to do key distribution and management (LetsEncrypt). Explaining and guiding people through that is the whole point.

0xbadcafebee 3y ago

> All issued SSL/TLS certificates are subject to certificate transparency. Until the nation state tells a CA within their borders to issue a cert without publishing the CT logs, along with a gag order. If they don't comply they go to jail. You think Billy Bob Sysadmin wants to go to jail to protect a russian jabber server?

bart__ 3y ago
Browsers will check if a certificate is in the transparency log, and alert the user if it isn't if I am not mistaken.
- deleted 3y ago
  [deleted]
- crtasm 3y ago
  But XMPP clients do not, as far as I'm aware? and browsers aren't connecting to XMPP server ports.
  - est31 3y ago
    Yeah usually the TLS libraries used by XMPP clients don't check SCTs. Not even all browsers do it. Chrome does it, Firefox does not for example.
- privacyking 3y ago
  Source?
  - bart__ 3y ago
    https://developer.mozilla.org/en-US/docs/Web/Security/Certificate_Transparency#browser_requirements https://developer.mozilla.org/en-US/docs/Web/Security/Certif... As the other commenter already pointed out, Firefox does not require this. Safari and Chrome do. This indeed is not directly applicable to this situation, since XMPP don't involve browsers. But for websites, the parents attack scenario is not applicable.

abigail95 3y ago

If they have physical access to your server, they'll just go for that. With mild difficulty you can mirror the disk, net, and RAM of any "commodity" hardware.

codedokode 3y ago

[flagged]

lxgr 3y ago
How would you implement “strict checking” at scale and for free?
- codedokode 3y ago
  If they used DNS validation it would be better because there would be only one point of failure (DNS) rather than many (DNS and every ISP between CA and a site).
  - Jenda_ 3y ago
    The thread above (https://news.ycombinator.com/item?id=37958831 https://news.ycombinator.com/item?id=37958831) elaborates on how to force DNS validation and/or how to tie your private key with Let's Encrypt via DNS.
    - codedokode 3y ago
      Everyone needs to opt-in to use more secure methods and by default non-secure validation methods, which allow easy issuing fake certificates, are allowed. This is wrong.
      - Jenda_ 3y ago
        So, what should they do? No certificate without DNS record? Would this really help the overall state of affairs, or would most sites just not use HTTPS at all because it's "too complicated"?
        codedokode 3y ago
        The purpose of using HTTPS is to make connections more secure. Giving away SSL certificates to anyone does not serve this purpose.