6 ms·

One important difference: HTTP/2 requires* encryption. This makes getting up and running for local development and small deployments more difficult. * https://

• crankylinuxuser 8y ago
  I'm guessing they're not carving out a niche for self-signed certs? I think that would have been a fair balance, of setting a "this is a self-signed cert" instead of the current "YoUr WeBsIte IS UNSECURED" (which isn't actually true). Accepting and indicating self signed would also be handy in Tor's onion sites, since the only companies that will issue certs require EV2 and all your info and a pile of money. And Onioncerts are pretty much only Facebook's area :/
  • pilif 8y ago
    > (which isn't actually true) how would I discern your self-signed certificate from the one served by the person arp-spoofing the gateway in a Starbucks?
    • crankylinuxuser 8y ago
      No cert chain for starters. The better answer here is some sort of "self signed standard data" for non-CA certs. But right now, testing in a NAT using HTTP2 is a ugly nonstarter.
      • pilif 8y ago
        > No cert chain for starters. why would the person who arp-spoofs the gateway in the Starbucks not be able to fetch your self-signed cert chain and mint their own matching chain with the exact same metadata (but of course differing keys)?
        • crankylinuxuser 8y ago
          Then what's your proposal for NATted, self-contained (no gateway), and Tor Onion networks? Sure, if I have a public IP and DNS records pointing towards it, I'm served by LE or a multitude other vendors. But that's a small number of machines on any network.
          • nybble41 8y ago
            If you have a public DNS entry then you can get a certificate from Let's Encrypt using the DNS verification method, even if the name points to a private IP address. DANE would also be an option if it (and DNSSEC) were more widely implemented. Local name resolution (mDNS) could take a page from what Tor already does and encode the public key fingerprint into the domain name. If the key uniquely matches the domain (perhaps just the first part, e.g. b32-key-hash.friendly-name.local) then you automatically get the equivalent of domain validation. While, by itself, this doesn't prove that you're connected to the right domain, by bookmarking the page and visiting it only through that bookmark you would get the equivalent of trust-on-first-use. Browsers would just need to recognize this form of domain name and validate the key against the embedded hash instead of an external CA.
  • pdpi 8y ago
    The only people who ever see the “this is insecure” page when it is actually a perfectly fine self-signed certificate know better. If you special-case self signed certificates, at it looks any less threatening, you will eventually have that page presented to unsuspecting victims.
  • muthdra 8y ago
    Dude, we don't use certs because we think they're cute. We use certs to guarantee cross-checking validation of resources. If you make me a certificate for your own website, I don't care how beautiful that cert is, it is also useless for cross-checking.
• kevin_b_er 8y ago
  As such, we know this statement to be false: "With WebSocket HTTP/2 support there is nothing that HTTP/1.1 can do that HTTP/2 cannot"
  • deleted 8y ago
    [deleted]