3 ms·

Would very glad to use HTTP/3, but as I make intranet appliances, cannot use it without a certificate. Is there any way to use it without cert? I've toyed with

by Roklem 2y ago

Would very glad to use HTTP/3, but as I make intranet appliances, cannot use it without a certificate. Is there any way to use it without cert? I've toyed with the idea of generating DNS names for static IP addresses with an * cert. Does anyone know if such a thing exist?

stavros 2y ago
Hm, why can you not generate certificates for intranet appliances? All you need is a domain.
- deleted 2y ago
  [deleted]
- quohort 2y ago
  a domain is a big ask for some p2p applications. Not only does it cost money, but you have to interact with a (central) domain registry, which defeats the purpose. There really ought to be a system (like .onion services or eepsites but without the mixnet/anonyminity) where you can just register a domain by a public key and have a signed pointer to your address on the internet as DHT. Sort of like IPNS or GNS but more common so you can just point someone to a domain like "0x1234[...]ABCD.ed25519.pubkey" and they can get a secure connection to you at whatever address you have.
  - stavros 2y ago
    Sounds like Namebase.
    - quohort 2y ago
      Sort of. The solution i'm suggesting would occupy the "decentralized" and "secure" position of zooko's triangle (https://en.wikipedia.org/wiki/Zooko%27s_triangle https://en.wikipedia.org/wiki/Zooko%27s_triangle). Whereas the problem that Namecoin, ENS, and others (presumably namebase as well?) are trying to solve is squaring the whole triangle with a petname system that sacrifices security for human-meaningful names. They are what's referred to as a petname system.
superkuh 2y ago
There is not. You could compile the HTTP/3 libs with the flag enabled and the link that library when you compile your browser with the appropriate flags (but there's no sure thing this will be possible). And for 99.9999% of the people on the web their browser/user-agent will be unable to establish a connection to an HTTP/3 listening server that does not have a CA TLS cert. It's the worst aspect of HTTP/3. It makes all web things require CA TLS and means that if something in the TLS breaks (as it does every couple years with root cert expirations, version obsolecence, acme version obsolecence, etc) then the website is not accessible. Because there's no such thing as HTTP+HTTPS HTTP/3. There is only HTTPS. It's designed entirely around corporate/institutional needs and is a terrible protocol for human people. HTTP+HTTPS websites can last decades without admin work. HTTP/3 websites can only last a few years at most.
fragmede 2y ago
could also install your own CA

by Roklem 2y ago

stavros 2y ago

Hm, why can you not generate certificates for intranet appliances? All you need is a domain.

deleted 2y ago
[deleted]
quohort 2y ago
a domain is a big ask for some p2p applications. Not only does it cost money, but you have to interact with a (central) domain registry, which defeats the purpose. There really ought to be a system (like .onion services or eepsites but without the mixnet/anonyminity) where you can just register a domain by a public key and have a signed pointer to your address on the internet as DHT. Sort of like IPNS or GNS but more common so you can just point someone to a domain like "0x1234[...]ABCD.ed25519.pubkey" and they can get a secure connection to you at whatever address you have.
- stavros 2y ago
  Sounds like Namebase.
  - quohort 2y ago
    Sort of. The solution i'm suggesting would occupy the "decentralized" and "secure" position of zooko's triangle (https://en.wikipedia.org/wiki/Zooko%27s_triangle https://en.wikipedia.org/wiki/Zooko%27s_triangle). Whereas the problem that Namecoin, ENS, and others (presumably namebase as well?) are trying to solve is squaring the whole triangle with a petname system that sacrifices security for human-meaningful names. They are what's referred to as a petname system.

superkuh 2y ago

There is not. You could compile the HTTP/3 libs with the flag enabled and the link that library when you compile your browser with the appropriate flags (but there's no sure thing this will be possible). And for 99.9999% of the people on the web their browser/user-agent will be unable to establish a connection to an HTTP/3 listening server that does not have a CA TLS cert. It's the worst aspect of HTTP/3. It makes all web things require CA TLS and means that if something in the TLS breaks (as it does every couple years with root cert expirations, version obsolecence, acme version obsolecence, etc) then the website is not accessible. Because there's no such thing as HTTP+HTTPS HTTP/3. There is only HTTPS. It's designed entirely around corporate/institutional needs and is a terrible protocol for human people. HTTP+HTTPS websites can last decades without admin work. HTTP/3 websites can only last a few years at most.

fragmede 2y ago

could also install your own CA