4 ms·

Is there any reason the certificates can't be signed by a valid certificate authority as they should be for HTTPS sites?

by nsgi 11y ago

raimue 11y ago
SSL certs from existing CAs can be used for anything, not just HTTPS.
- blibble 11y ago
  just no clients check it, or check it properly
  - raimue 11y ago
    Browsers also used to allow you to simply override invalid SSL certificates. Over time, it became more difficult and finally it is not even possible anymore when the server sent HSTS headers before. The current draft for IRCv3.3 of the IRCv3 working group already has a draft for Strict Transport Security, see http://ircv3.net/specs/core/sts-3.3.html http://ircv3.net/specs/core/sts-3.3.html We need the same culture shift in IRC clients that took place in browsers. Every IRC client should take certificate validation serious and do it properly. For that to happen, we need more SSL-enabled IRC servers and users that want to use it.
kbuck 11y ago
Until recently, getting certificates that would work for IRC purposes has been rather difficult. Since individual IRC servers are usually available via multiple hostnames, it requires very expensive certificates (e.g. someserver.example.net's IP address might also be present in the irc.example.net, us.irc.example.net, ipv6.irc.example.net, ... DNS records). Your options consisted of getting a "Subject Alternative Name" cert with all of these subdomains, or getting a (very expensive) wildcard certificate. IRC networks don't generally have much/any money to work with and this can easily start running into hundreds of dollars per year (especially if you deploy it properly and get one cert per server). It's theoretically possible to deploy Let's Encrypt now for IRC servers, which removes the cost issue. The new problems become the automated creation and deployment of IRC server certificates. You'll most likely need to use the DNS-01 challenge type, since most IRC servers aren't running a HTTPd and even if they were, you couldn't guarantee that the ACME server would pick the IP of the actual requesting server out of the "pool" records (e.g. irc.example.net). Using DNS-01 means you'll need to write code to interface with your DNS server, which also means securing that interaction (so other people can't modify your DNS records and get signed certs for your domain as well). I actually manage the (signed) certificates for one of the IRC networks I'm an administrator for. Our two blockers for deploying Let's Encrypt are the aforementioned challenges with DNS-01, and the fact that our software currently validates server-to-server links using the fingerprint of each server's individual certificate, hardcoded into the configuration file. If we're switching certs every 3 months, we'll need some way to either distribute certificate configuration more efficiently or we'll need to change the ircd to verify the certificate chain instead of the fingerprint. FWIW, our current deployment of signed certs is the "one cert to rule them all" deployed to all servers on our network. This is definitely not ideal, but it's by far the cheapest and easiest option prior to Let's Encrypt. All other options we evaluated were simply way too expensive ($X,000+), extremely labor-intensive (e.g. manually obtaining a new cert for every single server every year/every time something changed), or both.
- pfg 11y ago
  If dns-01 is currently a blocker for you, and you're willing to run a HTTPd on each server, there might be another option: Redirect all challenge requests (i.e. requests to .well-known/acme-challenge) to a common verification server (i.e. http://irc.example.com/.well-known/acme-challenge/token http://irc.example.com/.well-known/acme-challenge/token -> http://verification.example.com/.well-known/acme-challenge/token http://verification.example.com/.well-known/acme-challenge/t...). That way, you can run the client on verification.example.com and don't have to deal with distributing the challenge token to all nodes. The verification server can then distribute the certificates and keys to your nodes. That's one of the recommended solutions for shared-hosting providers who don't want to use DNS-based validation.
  - kbuck 11y ago
    DNS-01 is currently available (at least I believe it is -- I think I saw something about its availability recently). The issue is that I will need to write my own DNS-01 client. Running a HTTPd on each server is a bad idea for us since it increases DDoS attack surface area. This would essentially have the same distribution issue that I would need to solve with a DNS-01 client as well, so either way new code is required.
    - pfg 11y ago
      Yep, dns-01 went live in January. If your DNS server happens to support RFC 2136, take a look at lego[1] - some other provider-specific plugins for DNS are included as well. [1]: https://github.com/xenolf/lego https://github.com/xenolf/lego
      - kbuck 11y ago
        I'm not too worried about the DNS integration; we have a fairly easily-automatable DNS infrastructure owing to the fact that we're frequently changing records around. I'll have to see if we can take advantage of lego to avoid some work on our side.
    - walrus01 11y ago

Is there any reason the certificates can't be signed by a valid certificate authority as they should be for HTTPS sites?

by nsgi 11y ago

Is there any reason the certificates can't be signed by a valid certificate authority as they should be for HTTPS sites?

raimue 11y ago

SSL certs from existing CAs can be used for anything, not just HTTPS.

blibble 11y ago
just no clients check it, or check it properly
- raimue 11y ago
  Browsers also used to allow you to simply override invalid SSL certificates. Over time, it became more difficult and finally it is not even possible anymore when the server sent HSTS headers before. The current draft for IRCv3.3 of the IRCv3 working group already has a draft for Strict Transport Security, see http://ircv3.net/specs/core/sts-3.3.html http://ircv3.net/specs/core/sts-3.3.html We need the same culture shift in IRC clients that took place in browsers. Every IRC client should take certificate validation serious and do it properly. For that to happen, we need more SSL-enabled IRC servers and users that want to use it.

kbuck 11y ago

Until recently, getting certificates that would work for IRC purposes has been rather difficult. Since individual IRC servers are usually available via multiple hostnames, it requires very expensive certificates (e.g. someserver.example.net's IP address might also be present in the irc.example.net, us.irc.example.net, ipv6.irc.example.net, ... DNS records). Your options consisted of getting a "Subject Alternative Name" cert with all of these subdomains, or getting a (very expensive) wildcard certificate. IRC networks don't generally have much/any money to work with and this can easily start running into hundreds of dollars per year (especially if you deploy it properly and get one cert per server). It's theoretically possible to deploy Let's Encrypt now for IRC servers, which removes the cost issue. The new problems become the automated creation and deployment of IRC server certificates. You'll most likely need to use the DNS-01 challenge type, since most IRC servers aren't running a HTTPd and even if they were, you couldn't guarantee that the ACME server would pick the IP of the actual requesting server out of the "pool" records (e.g. irc.example.net). Using DNS-01 means you'll need to write code to interface with your DNS server, which also means securing that interaction (so other people can't modify your DNS records and get signed certs for your domain as well). I actually manage the (signed) certificates for one of the IRC networks I'm an administrator for. Our two blockers for deploying Let's Encrypt are the aforementioned challenges with DNS-01, and the fact that our software currently validates server-to-server links using the fingerprint of each server's individual certificate, hardcoded into the configuration file. If we're switching certs every 3 months, we'll need some way to either distribute certificate configuration more efficiently or we'll need to change the ircd to verify the certificate chain instead of the fingerprint. FWIW, our current deployment of signed certs is the "one cert to rule them all" deployed to all servers on our network. This is definitely not ideal, but it's by far the cheapest and easiest option prior to Let's Encrypt. All other options we evaluated were simply way too expensive ($X,000+), extremely labor-intensive (e.g. manually obtaining a new cert for every single server every year/every time something changed), or both.

pfg 11y ago
If dns-01 is currently a blocker for you, and you're willing to run a HTTPd on each server, there might be another option: Redirect all challenge requests (i.e. requests to .well-known/acme-challenge) to a common verification server (i.e. http://irc.example.com/.well-known/acme-challenge/token http://irc.example.com/.well-known/acme-challenge/token -> http://verification.example.com/.well-known/acme-challenge/token http://verification.example.com/.well-known/acme-challenge/t...). That way, you can run the client on verification.example.com and don't have to deal with distributing the challenge token to all nodes. The verification server can then distribute the certificates and keys to your nodes. That's one of the recommended solutions for shared-hosting providers who don't want to use DNS-based validation.
- kbuck 11y ago
  DNS-01 is currently available (at least I believe it is -- I think I saw something about its availability recently). The issue is that I will need to write my own DNS-01 client. Running a HTTPd on each server is a bad idea for us since it increases DDoS attack surface area. This would essentially have the same distribution issue that I would need to solve with a DNS-01 client as well, so either way new code is required.
  - pfg 11y ago
    Yep, dns-01 went live in January. If your DNS server happens to support RFC 2136, take a look at lego[1] - some other provider-specific plugins for DNS are included as well. [1]: https://github.com/xenolf/lego https://github.com/xenolf/lego
    - kbuck 11y ago
      I'm not too worried about the DNS integration; we have a fairly easily-automatable DNS infrastructure owing to the fact that we're frequently changing records around. I'll have to see if we can take advantage of lego to avoid some work on our side.
  - walrus01 11y ago