3 ms·

This is grossly irresponsible.

by skyzyx 6y ago

nexuist 6y ago
It's a joke, no? Nobody in their right mind would actually use this in production (of course, now that I've said that, they will, but I digress).
- el_dev_hell 6y ago
  It's 100% a joke and will 100% end up being used in production eventually.
  - pilif 6y ago
    For this to be useful in production, it would need to be signed by a proper CA. No CA will sign this. And if they accidentally did, it would be revoked immediately in order to not end up like Diginotar and Symantec
    - squiggleblaz 6y ago
      Diginotar and Symantec ended up like Diginotar and Symantec. Even Let's Encrypt backed down. There seems to be strong pressure on CAs to not do the secure thing when they've made a mistake.
- jeroenhd 6y ago
  You say that, but: https://github.com/flotwig/the-one-cert/issues/2 https://github.com/flotwig/the-one-cert/issues/2
dtech 6y ago
A valid use case would be local development or MITM'ing yourself
- mike_d 6y ago
  MITM proxies ran by organizations (governments) that also own certificate authorities is exactly why certificates like this are rejected by browsers on syntax alone. You can't wildcard at the root or TLD, and you can't have two wildcard labels in a DNS name.
  - jeroenhd 6y ago
    Browsers not only accept MitM certificates, they have special exceptions for them. If you import a CA certificate, Chrome and Firefox will ignore certain features (such as certificate transparency requirements) even for domains and IPs that resolve to the routable internet. The go-to solution for this is to load a certificate authority into the proxy itself and have it generate certificates on the fly. I think the wildcard rules are more to protect people in case of a certificate authority breach than to protect against MitM. Imagine if DigiNotar would sign a certificate in the form of ⁎.⁎.⁎ instead of just some Google domains and browser would actually accept that!
    - mike_d 6y ago
      Yes, the _correct_ way to do it is with a CA certificate. But since CA certificates do not have a CommonName or SAN, you have to have clients that support SNI so you know what host the client is requesting so you can quickly generate and sign a one-off certificate. The browser restrictions were in place before SNI was really widespread, and you needed funky certificates like the one in the original link because you had no way to predict if someone was trying to access google.com or facebook.com and you risked generating a browser warning if you offered up the wrong one.
- deleted 6y ago
  [deleted]

This is grossly irresponsible.

by skyzyx 6y ago

This is grossly irresponsible.

It's a joke, no? Nobody in their right mind would actually use this in production (of course, now that I've said that, they will, but I digress).

el_dev_hell 6y ago
It's 100% a joke and will 100% end up being used in production eventually.
- pilif 6y ago
  For this to be useful in production, it would need to be signed by a proper CA. No CA will sign this. And if they accidentally did, it would be revoked immediately in order to not end up like Diginotar and Symantec
  - squiggleblaz 6y ago
    Diginotar and Symantec ended up like Diginotar and Symantec. Even Let's Encrypt backed down. There seems to be strong pressure on CAs to not do the secure thing when they've made a mistake.
jeroenhd 6y ago
You say that, but: https://github.com/flotwig/the-one-cert/issues/2 https://github.com/flotwig/the-one-cert/issues/2

dtech 6y ago

A valid use case would be local development or MITM'ing yourself

mike_d 6y ago
MITM proxies ran by organizations (governments) that also own certificate authorities is exactly why certificates like this are rejected by browsers on syntax alone. You can't wildcard at the root or TLD, and you can't have two wildcard labels in a DNS name.
- jeroenhd 6y ago
  Browsers not only accept MitM certificates, they have special exceptions for them. If you import a CA certificate, Chrome and Firefox will ignore certain features (such as certificate transparency requirements) even for domains and IPs that resolve to the routable internet. The go-to solution for this is to load a certificate authority into the proxy itself and have it generate certificates on the fly. I think the wildcard rules are more to protect people in case of a certificate authority breach than to protect against MitM. Imagine if DigiNotar would sign a certificate in the form of ⁎.⁎.⁎ instead of just some Google domains and browser would actually accept that!
  - mike_d 6y ago
    Yes, the _correct_ way to do it is with a CA certificate. But since CA certificates do not have a CommonName or SAN, you have to have clients that support SNI so you know what host the client is requesting so you can quickly generate and sign a one-off certificate. The browser restrictions were in place before SNI was really widespread, and you needed funky certificates like the one in the original link because you had no way to predict if someone was trying to access google.com or facebook.com and you risked generating a browser warning if you offered up the wrong one.
deleted 6y ago
[deleted]