4 ms·

Operating a private CA is trivial, there are packages to automate it at every level from simple manual scripting to fully-automated ACME servers such as Boulder

Operating a private CA is trivial, there are packages to automate it at every level from simple manual scripting to fully-automated ACME servers such as Boulder[0]. For proprietary software it's idiomatic to use a private CA for securing connections to a central server, to avoid the risk of DNS hijacking or a malicious third-party CA. For open-source software it will, definitionally, allow substituting different server key validation options for users who prefer to run their own servers. The only real problem QUIC's mandatory TLS causes is that localhost development becomes marginally more difficult, but even as someone who loves running my in-development stuff on localhost it's clear that the security of the internet as a whole is of far greater value. [0] https://github.com/letsencrypt/boulder https://github.com/letsencrypt/boulder

superkuh 4y ago
Operating a private CA + QUIC does not allow me to host my own website that is visitable by a random person on the internet. HTTP/1.1 does. Private CAs solve other problems for internal uses but not this big important one for the public web.
- jmillikin 4y ago
  HTTP over plaintext TCP is obsolete in a similar way to Telnet (vs SSH) or FTP (vs SFTP). It took something like 20 years for support for FTP to be dropped from major user agents[0]. By the time the major browsers drop support for plaintext HTTP, that protocol will be as quaint and archaic as Gopher is today. (and we'll all be better off for it -- good riddance to anything ASCII-based or unauthenticated) [0] https://blog.mozilla.org/security/2021/07/20/stopping-ftp-support-in-firefox-90/ https://blog.mozilla.org/security/2021/07/20/stopping-ftp-su...
  - superkuh 4y ago
    I think even you will be surprised how fast Google drops HTTP/1.1 support in Chrome. Humanity won't be better off for it but commerce certainly will. And I guess that's all that matters.
  - 0x000xca0xfe 4y ago
    HTTP/1.1 is not obsolete -- HTTP/2 and HTTP/3 preserve basically all semantics. HTTP/1 is better than 2 and 3 in many cases, e.g. when you cannot afford the complexity like in tiny embedded devices, or when you just need to bootstrap a WebSocket, or you don't need TLS. HTTP/1.1 will be obsolete when intranets and tiny devices are obsolete. Well, it looks like that could become true...
    - deleted 4y ago
      [deleted]
  - skissane 4y ago
    > HTTP over plaintext TCP is obsolete in a similar way to Telnet (vs SSH) or FTP (vs SFTP). That’s not comparing apples and oranges-HTTPS was originally just (and often still is just) plaintext HTTP/1.x wrapped in TLS. Whereas, SFTP and SSH are not FTP/TELNET over TLS, they are completely separate protocols. FTPS and TELNETS are the original protocols over TLS, but have seen only limited adoption (mostly in mainframe environments, in which SSH and SFTP perform poorly.) Even HTTP 2 and 3 are just a binary encoding of the HTTP/1.x protocol over an encrypted transport. By contrast, SSH and SFTP are essentially unrelated protocols to TELNET and FTP, as opposed to just binary encodings of them. (The TELNET protocol is already non-text-based anyway-the data may be mostly text but the control messages have never been.)
  - ahefner 4y ago
    This take is really not crediting the different threat models motivating SSH versus HTTPS. In both cases the network is considered untrusted, but beyond this the analogy largely fails - almost every application of telnet risks leaking authentication credentials to an eavesdropper (in addition to allowing them to subsequently surveil your session), whereas the classical HTTP use case is to retrieve information anonymously. I cheered the widespread move toward HTTPS as a response to outrageous behavior by certain ISPs and their modifying/injecting content into sessions, which arguably should be criminalized, yet if the forces of abusive service providers and unaccountable state security agencies is becoming so omnipresent that we can only retreat beyond a veil of encryption, we are living in very dark times. I'd be more optimistic if not for the (cynical?) fear that those most in need of encryption will be the first to be denied it by the force of the state, a day only accelerated by its increasing ubiquity. Your government can force you to install a state-sanctioned CA cert, almost entirely undermining TLS from that perspective, which Google can/will do nothing to resist, and their parallel desire to deprecate plaintext HTTP is entirely orthogonal to this.
- jayd16 4y ago
  I guess you could still use a self signed cert if your users accept unsigned anyway.
- kevstev 4y ago
  I am continually shocked at how few people actually care about this. Maybe I am just showing my age, because I remember in college, and even when I got my first cable modem, I could easily just spin up apache or IIS and have a website hosted from my house, with no additional money or hoops required- start up a webserver, pop in the IP into my browser, or my dynamic dns, and there we were on the web! This lead to all kinds of experimentation and such, even if I did get "hacked by Chinese!" when I had IIS running around 2001ish. Google has been doing a great job of killing the "personal internet" by making it undiscoverable for several years, but now that we require a third party to somehow be involved, and likely a fee of some sort to be paid- I don't trust that the likes of Lets Encrypt and its duplicators to be available forever, the original "anyone can publish" dream of the web is dying in front of us. This: https://justinjackson.ca/words.html https://justinjackson.ca/words.html does not require SSL in any form, in fact most websites don't need it at all- and the obsession with even blogs wanting you to make accounts and to have to login, its all just heading in a very wrong direction. Its just deplorable to me that I now need a third party to essentially tell me that I can be on the Internet. Its a huge step backwards in so many ways. And no one seems to care!
  - dinosaurdynasty 4y ago
    Caddy is just as easier if not easier than that. > Its just deplorable to me that I now need a third party You've always needed one or more third parties (ISPs, backbone, ICANN, etc), this is no different.
    - jgwil2 4y ago
      It's another barrier that's been added, perhaps for good reason, but it is a tradeoff worthy of debate.
- tenebrisalietum 4y ago
  > Operating a private CA ... does not allow me to host my own website that is visitable by a random person on the internet. It does if they install the CA cert. UI is not pretty, but not insurmountable on standard browsers, OSs, or phones, and there is no interference unless you are working on a domain-joined Windows PC or your phone is under some sort of MDM. These UI issues with this process could be resolved by some browser UI work by parties that aren't interested in perpetuating the current status quo and can get past handholding boomers apparently willing to enter bank credentials into anything that moves. Or just use Gemini.
  - jakeogh 4y ago
    Neat. Project Gemini: https://gemini.circumlunar.space/docs/specification.html https://gemini.circumlunar.space/docs/specification.html 4.2 Server certificate validation Clients can validate TLS connections however they like (including not at all) but the strongly RECOMMENDED approach is to implement a lightweight "TOFU" certificate-pinning system which treats self-signed certificates as first- class citizens. This greatly reduces TLS overhead on the network (only one cert needs to be sent, not a whole chain) and lowers the barrier to entry for setting up a Gemini site (no need to pay a CA or setup a Let's Encrypt cron job, just make a cert and go). I'm surprised to not see an optional response size field in the response header. How does the client calculate progress%? Reading....
  - GekkePrutser 4y ago
    > UI is not pretty, but not insurmountable on standard browsers, OSs, or phones, and there is no interference unless you are working on a domain-joined Windows PC or your phone is under some sort of MDM. The problem is that while you can still add root CAs on modern Android, apps have to specifically opt-in to user-added root CAs. They can ignore them as they wish and I believe they have to even opt in to third-party CAs. Needless to say most apps don't bother. This is a big problem with self-signed certs on Android. I believe this was changed in version 7 or so. Not sure how this works on iOS but on Android it's really a problem.
    - tenebrisalietum 4y ago
FuriouslyAdrift 4y ago
Bulder is not suited for production use as per it's own docs... "It is not suitable for use as a production environment."

superkuh 4y ago

Operating a private CA + QUIC does not allow me to host my own website that is visitable by a random person on the internet. HTTP/1.1 does. Private CAs solve other problems for internal uses but not this big important one for the public web.

jmillikin 4y ago
HTTP over plaintext TCP is obsolete in a similar way to Telnet (vs SSH) or FTP (vs SFTP). It took something like 20 years for support for FTP to be dropped from major user agents[0]. By the time the major browsers drop support for plaintext HTTP, that protocol will be as quaint and archaic as Gopher is today. (and we'll all be better off for it -- good riddance to anything ASCII-based or unauthenticated) [0] https://blog.mozilla.org/security/2021/07/20/stopping-ftp-support-in-firefox-90/ https://blog.mozilla.org/security/2021/07/20/stopping-ftp-su...
- superkuh 4y ago
  I think even you will be surprised how fast Google drops HTTP/1.1 support in Chrome. Humanity won't be better off for it but commerce certainly will. And I guess that's all that matters.
- 0x000xca0xfe 4y ago
  HTTP/1.1 is not obsolete -- HTTP/2 and HTTP/3 preserve basically all semantics. HTTP/1 is better than 2 and 3 in many cases, e.g. when you cannot afford the complexity like in tiny embedded devices, or when you just need to bootstrap a WebSocket, or you don't need TLS. HTTP/1.1 will be obsolete when intranets and tiny devices are obsolete. Well, it looks like that could become true...
  - deleted 4y ago
    [deleted]
- skissane 4y ago
  > HTTP over plaintext TCP is obsolete in a similar way to Telnet (vs SSH) or FTP (vs SFTP). That’s not comparing apples and oranges-HTTPS was originally just (and often still is just) plaintext HTTP/1.x wrapped in TLS. Whereas, SFTP and SSH are not FTP/TELNET over TLS, they are completely separate protocols. FTPS and TELNETS are the original protocols over TLS, but have seen only limited adoption (mostly in mainframe environments, in which SSH and SFTP perform poorly.) Even HTTP 2 and 3 are just a binary encoding of the HTTP/1.x protocol over an encrypted transport. By contrast, SSH and SFTP are essentially unrelated protocols to TELNET and FTP, as opposed to just binary encodings of them. (The TELNET protocol is already non-text-based anyway-the data may be mostly text but the control messages have never been.)
- ahefner 4y ago
  This take is really not crediting the different threat models motivating SSH versus HTTPS. In both cases the network is considered untrusted, but beyond this the analogy largely fails - almost every application of telnet risks leaking authentication credentials to an eavesdropper (in addition to allowing them to subsequently surveil your session), whereas the classical HTTP use case is to retrieve information anonymously. I cheered the widespread move toward HTTPS as a response to outrageous behavior by certain ISPs and their modifying/injecting content into sessions, which arguably should be criminalized, yet if the forces of abusive service providers and unaccountable state security agencies is becoming so omnipresent that we can only retreat beyond a veil of encryption, we are living in very dark times. I'd be more optimistic if not for the (cynical?) fear that those most in need of encryption will be the first to be denied it by the force of the state, a day only accelerated by its increasing ubiquity. Your government can force you to install a state-sanctioned CA cert, almost entirely undermining TLS from that perspective, which Google can/will do nothing to resist, and their parallel desire to deprecate plaintext HTTP is entirely orthogonal to this.
jayd16 4y ago
I guess you could still use a self signed cert if your users accept unsigned anyway.
kevstev 4y ago
I am continually shocked at how few people actually care about this. Maybe I am just showing my age, because I remember in college, and even when I got my first cable modem, I could easily just spin up apache or IIS and have a website hosted from my house, with no additional money or hoops required- start up a webserver, pop in the IP into my browser, or my dynamic dns, and there we were on the web! This lead to all kinds of experimentation and such, even if I did get "hacked by Chinese!" when I had IIS running around 2001ish. Google has been doing a great job of killing the "personal internet" by making it undiscoverable for several years, but now that we require a third party to somehow be involved, and likely a fee of some sort to be paid- I don't trust that the likes of Lets Encrypt and its duplicators to be available forever, the original "anyone can publish" dream of the web is dying in front of us. This: https://justinjackson.ca/words.html https://justinjackson.ca/words.html does not require SSL in any form, in fact most websites don't need it at all- and the obsession with even blogs wanting you to make accounts and to have to login, its all just heading in a very wrong direction. Its just deplorable to me that I now need a third party to essentially tell me that I can be on the Internet. Its a huge step backwards in so many ways. And no one seems to care!
- dinosaurdynasty 4y ago
  Caddy is just as easier if not easier than that. > Its just deplorable to me that I now need a third party You've always needed one or more third parties (ISPs, backbone, ICANN, etc), this is no different.
  - jgwil2 4y ago
    It's another barrier that's been added, perhaps for good reason, but it is a tradeoff worthy of debate.
tenebrisalietum 4y ago
> Operating a private CA ... does not allow me to host my own website that is visitable by a random person on the internet. It does if they install the CA cert. UI is not pretty, but not insurmountable on standard browsers, OSs, or phones, and there is no interference unless you are working on a domain-joined Windows PC or your phone is under some sort of MDM. These UI issues with this process could be resolved by some browser UI work by parties that aren't interested in perpetuating the current status quo and can get past handholding boomers apparently willing to enter bank credentials into anything that moves. Or just use Gemini.
- jakeogh 4y ago
  Neat. Project Gemini: https://gemini.circumlunar.space/docs/specification.html https://gemini.circumlunar.space/docs/specification.html 4.2 Server certificate validation Clients can validate TLS connections however they like (including not at all) but the strongly RECOMMENDED approach is to implement a lightweight "TOFU" certificate-pinning system which treats self-signed certificates as first- class citizens. This greatly reduces TLS overhead on the network (only one cert needs to be sent, not a whole chain) and lowers the barrier to entry for setting up a Gemini site (no need to pay a CA or setup a Let's Encrypt cron job, just make a cert and go). I'm surprised to not see an optional response size field in the response header. How does the client calculate progress%? Reading....
- GekkePrutser 4y ago
  > UI is not pretty, but not insurmountable on standard browsers, OSs, or phones, and there is no interference unless you are working on a domain-joined Windows PC or your phone is under some sort of MDM. The problem is that while you can still add root CAs on modern Android, apps have to specifically opt-in to user-added root CAs. They can ignore them as they wish and I believe they have to even opt in to third-party CAs. Needless to say most apps don't bother. This is a big problem with self-signed certs on Android. I believe this was changed in version 7 or so. Not sure how this works on iOS but on Android it's really a problem.
  - tenebrisalietum 4y ago

FuriouslyAdrift 4y ago

Bulder is not suited for production use as per it's own docs... "It is not suitable for use as a production environment."