Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The HTTP crash course nobody asked for

fasterthanli.me

Post reply on HN
Print view View original

91–100 of 149 posts

Re: The HTTP crash course nobody asked for

#91

Post by bornfreddy »

rootusrootus wrote: post #80
insanitybit wrote: post #76

Earlier quoted context omitted.

Can you not just have it use a self signed certificate? I don't see why a CA would need to be involved at all, nor can I even imagine how that could be enforced at the protocol level. This sounds like a red herring to me. edit: Yeah I've more or less confirmed that self signed certs are perfectly fine in HTTP3. This is a big ball of nothing.

About half my personal (private, in my own home LAN) sites use self-signed certs that Chrome flat out won't accept. I have to type the magic key sequence to bypass the error. I do wish we could come up with something better for this kind of use case, then having to set up letsencrypt on my public domain and issue a wildcard cert to use with RFC1918 web sites. And that's without worrying about HTTP/3.

> I have to type the magic key sequence to bypass the error.

8 keys? f + i + r + e + f + o + x + Enter?

Re: The HTTP crash course nobody asked for

#92

Post by HideousKojima »

bak3y wrote: post #71
fasterthanlime wrote: post #56

Earlier quoted context omitted.

You know how some movie fans will sometimes pretend the sequels to some franchise don't exist? HTTP is the opposite.

So HTTP is the old school Star Wars fans pretending the prequels don't exist?

Nah it's the Buffy TV show fans ignoring the movie

Re: The HTTP crash course nobody asked for

#93

Post by count »

bornfreddy wrote: post #91
rootusrootus wrote: post #80

Earlier quoted context omitted.

About half my personal (private, in my own home LAN) sites use self-signed certs that Chrome flat out won't accept. I have to type the magic key sequence to bypass the error. I do wish we could come up with something better for this kind of use case, then having to set up letsencrypt on my public domain and issue a wildcard cert to use with RFC1918 web sites. And that's without worrying about HTTP/3.

> I have to type the magic key sequence to bypass the error. 8 keys? f + i + r + e + f + o + x + Enter?

'thisisunsafe' to answer the actual question

Re: The HTTP crash course nobody asked for

#94

Post by jallmann »

chrismorgan wrote: post #66
superkuh wrote: post #54

Earlier quoted context omitted.

HTTP/3 is written for the use case of large corporations and does not even allow for human persons to use it alone. It requires CA based TLS to set up a connection. So if you want to host a website visitable by a random person you've never communicated with before you have to get continued permission from an incorporated entity running a CA to do so. This is far more of a security problem than all of the bad HTTP 1.1…

Your complaint is strictly social, and quite irrelevant here. Look, cleartext internet protocols are on the way out, because their model is fundamentally broken. For security reasons, I will note, and privacy. There, we joust security against security. Cleartext HTTP/1 is strictly a legacy matter, retained only because there’s still too much content stuck on it. But browsers will be more aggressively phasing it out s…

It is a layering violation though. Not all HTTP usage is through a browser, and not all routes go over the plaintext Internet. Browsers or clients can still require HTTPS at the application layer, but it shouldn't be part of the protocol spec.

Suppose I have an app within an intranet that's secured with, say, Wireguard or an application-layer tunnel (eg, SSH or Openziti).

Bringing HTTP/3 into the picture means dealing with CAs and certs on top of the provisioning I've already done for my lower layers, possibly leaking information via Certificate Transparency logs. Then the cost of double-encryption, etc.

Re: The HTTP crash course nobody asked for

#96

Post by mistrial9 »

benmmurphy wrote: post #89
mistrial9 wrote: post #84

Earlier quoted context omitted.

ok $ curl -v https://self-signed.badssl.com/ * Trying 104.154.89.105:443... * Connected to self-signed.badssl.com (104.154.89.105) port 443 (#0) * ALPN, offering h2 * ALPN, offering http/1.1 * CAfile: /etc/ssl/certs/ca-certificates.crt * CApath: /etc/ssl/certs * TLSv1.0 (OUT), TLS header, Certificate Status (22): * TLSv1.3 (OUT), TLS handshake, Client hello (1): * TLSv1.2 (IN), TLS header, Certificate Status (22): *…

curl -kv https://self-signed.badssl.com/ * Trying 104.154.89.105:443... * TCP_NODELAY set * Connected to self-signed.badssl.com (104.154.89.105) port 443 (#0) * ALPN, offering http/1.1 * Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH * successfully set certificate verify locations: * CAfile: /opt/local/share/curl/curl-ca-bundle.crt CApath: none * TLSv1.2 (OUT), TLS header, Certificate St…

yes minus-k says "less checking, generally proceed" but does it remember that certificate? maybe not

Re: The HTTP crash course nobody asked for

#97

Post by jandrese »

danuker wrote: post #12
Donckele wrote: post #10

“By contrast, I think about Bluetooth a lot. I wish I didn't.” LOL, yes same here. Can’t wait for Bluetooths b̶a̶l̶l̶s̶ baggage to be chopped.

How is WiFi so much more reliable than Bluetooth? I installed a web server on my phone and send files this way much faster (and Android -> Apple works): https://f-droid.org/en/packages/net.basov.lws.fdroid/ I wish there were a standard for streaming (headphones could connect to your network via WPS, and stream some canonical URL with no configuration needed).

Bluetooth is massively more complicated than WiFi. It has a whole service enumeration/discovery layer baked in that IMHO tried to cram way too much into the spec. Whats even more amazing is that some of the hardware vendors at the table during the development went "F that" and added some side channel audio stuff that bypassing most of the stack.

But mostly the problem is that too much of this complexity fell on hardware vendors and they suck at writing software. There are umpteen bajillion different bluetooth stacks out there and they're all buggy in new and exciting ways. Interoperability testing is hugely neglected by most vendors. The times where Bluetooth works well are typically where the same vendor controls both ends of the link, like Airpods on an iPhone.

In 2020 I tried buying some reputable brand Bluetooth headphones for my kids so they could do home-schooling without disturbing each other. It was a total failure. Every time their computer went to sleep the bluetooth stack would become out of sync and attempts to reconnect would result in just "error connecting" messages, requiring you to fully delete the bluetooth device on the Windows side and redo the entire discovery/association/connection from scratch. The bluetooth stack on Windows would crash halfway through the association process about half of the time forcing you to reboot the computer to start over. Absolutely unusable. I tried the same headphones on a Linux host and they worked slightly better, but were still prone to getting out of sync and requiring a full "forget this device" and add it again cycle every few days for no apparent reason.

Re: The HTTP crash course nobody asked for

#98

Post by snowwrestler »

rootusrootus wrote: post #80
insanitybit wrote: post #76

Earlier quoted context omitted.

Can you not just have it use a self signed certificate? I don't see why a CA would need to be involved at all, nor can I even imagine how that could be enforced at the protocol level. This sounds like a red herring to me. edit: Yeah I've more or less confirmed that self signed certs are perfectly fine in HTTP3. This is a big ball of nothing.

About half my personal (private, in my own home LAN) sites use self-signed certs that Chrome flat out won't accept. I have to type the magic key sequence to bypass the error. I do wish we could come up with something better for this kind of use case, then having to set up letsencrypt on my public domain and issue a wildcard cert to use with RFC1918 web sites. And that's without worrying about HTTP/3.

If you control both the server and the client, you can make yourself your own private CA, issue all the certs you need, and have no browser errors anywhere.

Re: The HTTP crash course nobody asked for

#99

Post by themenomen »

chrismorgan wrote: post #66
superkuh wrote: post #54

Earlier quoted context omitted.

HTTP/3 is written for the use case of large corporations and does not even allow for human persons to use it alone. It requires CA based TLS to set up a connection. So if you want to host a website visitable by a random person you've never communicated with before you have to get continued permission from an incorporated entity running a CA to do so. This is far more of a security problem than all of the bad HTTP 1.1…

Your complaint is strictly social, and quite irrelevant here. Look, cleartext internet protocols are on the way out, because their model is fundamentally broken. For security reasons, I will note, and privacy. There, we joust security against security. Cleartext HTTP/1 is strictly a legacy matter, retained only because there’s still too much content stuck on it. But browsers will be more aggressively phasing it out s…

Thinking that social issues can't and should not shape technical discussions, even more when talking about one of the most important technological platforms for society is rather limited and short sighted.

Re: The HTTP crash course nobody asked for

#100

Post by rmckayfleming »

jandrese wrote: post #97
danuker wrote: post #12

Earlier quoted context omitted.

How is WiFi so much more reliable than Bluetooth? I installed a web server on my phone and send files this way much faster (and Android -> Apple works): https://f-droid.org/en/packages/net.basov.lws.fdroid/ I wish there were a standard for streaming (headphones could connect to your network via WPS, and stream some canonical URL with no configuration needed).

Bluetooth is massively more complicated than WiFi. It has a whole service enumeration/discovery layer baked in that IMHO tried to cram way too much into the spec. Whats even more amazing is that some of the hardware vendors at the table during the development went "F that" and added some side channel audio stuff that bypassing most of the stack. But mostly the problem is that too much of this complexity fell on hardw…

Yep, had a similar annoyance using my AirPods with my gaming laptop. The laptop wouldn't reconnect after going to sleep for an extended period of time. I ended up replacing the stock wireless card for an Intel AX210 based one and then it was fine.
Post reply on HN