Mediocre Engineer's Guide to HTTPS
devonperoutky.super.site
Mediocre Engineer's Guide to HTTPS
1–10 of 36 posts
Re: Mediocre Engineer's Guide to HTTPS
#2Tangential question from a layman: when I lose access to a particular website, or the internet as a whole, why is it so hard to tell where in the chain the failure is occurring? Like it’s often unclear whether
* I’ve got a network misconfiguration on my local machine;
* My wifi connection to the router is down;
* The cable between my router and ISP is cut;
* My ISP is having large scale issues; or
* The website I’m trying to reach is down.
I’ve been given the vague impression that it has something to do with a non-deterministic path by which requests are routed, but this seems unconvincing. If some link on the path breaks, why doesn’t the last good link send a message backward that says “Your message made it to me, but I tried to send it the next step and it failed there.”
Re: Mediocre Engineer's Guide to HTTPS
#3Tangential question from a layman: when I lose access to a particular website, or the internet as a whole, why is it so hard to tell where in the chain the failure is occurring? Like it’s often unclear whether * I’ve got a network misconfiguration on my local machine; * My wifi connection to the router is down; * The cable between my router and ISP is cut; * My ISP is having large scale issues; or * The website I’m t…
The browser reports the error closest to what it was doing at the time - host not found? Well, the network was reliable enough to reach a dns server that returned that the lack of address for a name. But if the dns server itself can’t come reached, it’s some sort of network error between you and that server. The typical way to diagnose that kind of problem is to perform all the steps yourself - can I ping the dns server address? Can I resolve this host with that dns server? What about a different dns server, maybe that particular name is being excluded because of corporate policy. The command line tools ping, traceroute and dig are useful if you want to get into it.
Re: Mediocre Engineer's Guide to HTTPS
#4Tangential question from a layman: when I lose access to a particular website, or the internet as a whole, why is it so hard to tell where in the chain the failure is occurring? Like it’s often unclear whether * I’ve got a network misconfiguration on my local machine; * My wifi connection to the router is down; * The cable between my router and ISP is cut; * My ISP is having large scale issues; or * The website I’m t…
Not a network person, only played with trace route a long time ago but I'm pretty sure that only really happens if you explicitly ask for information about all the middle men.
Most of the time a lot of software kinda doesn't care about what's happening just if it can do what it's told.
For Websites you often get more informative errors like 404, 500 or something else.
Re: Mediocre Engineer's Guide to HTTPS
#5Everything in that article is a little outdated, 30% of web request are in HTTP3 now a day with CORS. There is no date of publication.
Re: Mediocre Engineer's Guide to HTTPS
#6Everything in that article is a little outdated, 30% of web request are in HTTP3 now a day with CORS. There is no date of publication.
30% of requests are CORS? Surely this depends on what type of development you're doing. I'm doing SaaS development for systems generally deployed inside corporate networks. Very close to 0% of requests are CORS. Same for HTTP3.
Re: Mediocre Engineer's Guide to HTTPS
#7Tangential question from a layman: when I lose access to a particular website, or the internet as a whole, why is it so hard to tell where in the chain the failure is occurring? Like it’s often unclear whether * I’ve got a network misconfiguration on my local machine; * My wifi connection to the router is down; * The cable between my router and ISP is cut; * My ISP is having large scale issues; or * The website I’m t…
Not a network person, only played with trace route a long time ago but I'm pretty sure that only really happens if you explicitly ask for information about all the middle men. Most of the time a lot of software kinda doesn't care about what's happening just if it can do what it's told. For Websites you often get more informative errors like 404, 500 or something else.
If you're getting a status code like 404 or 500, it means there's no problem between you and the web server. The status codes come from the server. The exception is when you get a gateway/reverse proxy error. Usually 503 I think. That means the web server is down, but there's another server in front of it reporting that it's down.
Re: Mediocre Engineer's Guide to HTTPS
#8Tangential question from a layman: when I lose access to a particular website, or the internet as a whole, why is it so hard to tell where in the chain the failure is occurring? Like it’s often unclear whether * I’ve got a network misconfiguration on my local machine; * My wifi connection to the router is down; * The cable between my router and ISP is cut; * My ISP is having large scale issues; or * The website I’m t…
If ICMP is allowed into your network, your machine will most likely receive a Destination Unreachable response from the host that can't forward the packet further.
Your application won't see the ICMP message unless you configure the socket to report them(these are considered "transient" errors). On Linux this is done via the socket option IP_RECVERR.
ETA: there's not a ton of value collecting errors at this layer when you're working at L7. The errors that _do_ get surfaced for DU at your layer will be appropriate for the failure handling logic you'll inevitably have already. In this case I think it'd be a timeout, as other layers implement retries in the face of unreachable destinations.
I found these RFCs helpful re: how the TCP layer handles ICMP errors: https://www.rfc-editor.org/rfc/rfc1122#page-103
Section 4.2.3.9:
> Since these Unreachable messages indicate soft error conditions, TCP MUST NOT abort the connection, and it SHOULD make the information available to the application.
> DISCUSSION: TCP could report the soft error condition to the application layer with an upcall to the ERROR_REPORT routine, or it could merely note the message and report it to the application only when and if the TCP connection times out.
This one gets into the nitty gritty of how the stacks interact in order to study ICMP as vector for TCP attacks.
Re: Mediocre Engineer's Guide to HTTPS
#9Earlier quoted context omitted.
Not a network person, only played with trace route a long time ago but I'm pretty sure that only really happens if you explicitly ask for information about all the middle men. Most of the time a lot of software kinda doesn't care about what's happening just if it can do what it's told. For Websites you often get more informative errors like 404, 500 or something else.
If you're getting a status code like 404 or 500, it means there's no problem between you and the web server. The status codes come from the server. The exception is when you get a gateway/reverse proxy error. Usually 503 I think. That means the web server is down, but there's another server in front of it reporting that it's down.
True, I thought of those as they're just more informative about why you're not getting what you're looking for.
Re: Mediocre Engineer's Guide to HTTPS
#10> The client generates a premaster secret, encrypts it with the server’s public key, and sends it to the server.
It's already not true for, like, ages.