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

Mediocre Engineer's Guide to HTTPS

devonperoutky.super.site

Post reply on HN
Print view View original

11–20 of 36 posts

Re: Mediocre Engineer's Guide to HTTPS

#11

Post by arccy »

jessriedel wrote: post #2

Tangential 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…

http(s) is built on top of multiple layers (HTTP, TLS, TCP, Ethernet...). A broken link in the lower layers can't really be presented as a higher level message (because it has no access to it).

Re: Mediocre Engineer's Guide to HTTPS

#12

Post by YZF »

recursive wrote: post #7
harry_ord wrote: post #4

Earlier 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.

502 Bad Gateway.

Re: Mediocre Engineer's Guide to HTTPS

#13

Post by YZF »

jessriedel wrote: post #2

Tangential 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…

For most people most issues would in at their home network. So that's a good first guess for any connectivity problems. Rarely it would be somewhere between your home and the ISP. If it's a small rural ISP then it might be ISP->Internet though I'd think that's rare. Most large scale ISPs have enough redundancy and capacity.

As someone else mentioned ICMP addresses certain classes of failures if enabled but I think the historical reason is more along the lines of the Internet was meant to run over lossy connections. For example, when a certain link is saturated routers will just start dropping packets. Reporting each dropped packet back to the sender is just not a good idea, it adds load to a system already potentially operating at capacity. TCP assumes packets can get lost and retransmits them. When a link goes down routing protocols will potentially send those retransmitted packets over a different link/path. I.e. there's no real concept of "connection down" other than the application layer or TCP eventually giving up (which can take a very long time). The kind of ICMP message that will immediately terminate a connection is when the server machine doesn't have anything listening on the destination port.

Re: Mediocre Engineer's Guide to HTTPS

#14

Post by wonnage »

This reads like an AI summary of an actual HTTPS explainer. Terms get introduced with no context - no explanation of what a certificate is or how the chain of trust works, assumes the reader knows about public key cryptography, describes six out of the seven OSI layers (RIP presentation layer) without mentioning that term at all, etc.

TBF it is titled as mediocre!

Re: Mediocre Engineer's Guide to HTTPS

#15

Post by MediumD »

wonnage wrote: post #14

This reads like an AI summary of an actual HTTPS explainer. Terms get introduced with no context - no explanation of what a certificate is or how the chain of trust works, assumes the reader knows about public key cryptography, describes six out of the seven OSI layers (RIP presentation layer) without mentioning that term at all, etc. TBF it is titled as mediocre!

To be fair, I also didn’t include the session layer!

My writing isn’t a strength of mine, so I appreciate the criticism. My writing going from “bad” -> “is it AI?” is progress.

I struggled with where to “cutoff” the explanation and public key cryptography seemed like a good boundary and better explained elsewhere, as did various OSI layers.

I probably should have gone over the cert and potentially the full chain of trust, I’ll give you that.

Re: Mediocre Engineer's Guide to HTTPS

#16

Post by treflop »

jessriedel wrote: post #2

Tangential 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…

It’s possible to figure out exactly what failed if you know how it all works.

But to write a tool to provides a useful description to the user is near impossible because no two setups are the same, it’s not possible to know if something is intentional or not, and it can be dangerous to just make an assumption based on what the common causes are and just suggest to the user a completely wrong answer.

For example, let’s say you can’t connect to a website because the DNS server isn’t responding and the host isn’t responding. You could tell the user that something is probably misconfigured at your router or your ISP is having some issues.

However, it turns out that the actual reason was that your VPN client updated your local routing tables and DNS server but failed to remove the changes when you quit the client. How is a troubleshooter supposed to know that the settings were temporarily changed versus it being the permanent ones?

Once you try to start to write a troubleshooter that can identify the actual cause, you realize that it’s very difficult due to the complexity and variation. At best you can write something that usually spits out a correct answer but also sometimes suggests something totally wrong and leads people down a completely wrong path.

Re: Mediocre Engineer's Guide to HTTPS

#18

Post by Operyl »

Snawoot wrote: post #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.

Down below it says this:

> Everything you’ve learned here is a lie.

> The process we just describe is for the original version of TLS, which is outdated compared to the more modern version of TLS 1.3.

Re: Mediocre Engineer's Guide to HTTPS

#19

Post by jonwest »

Does anyone have more examples of articles written in this perspective? Regardless of my experience level I love diving through “ELI(a mediocre engineer)” type explanations as I either learn another piece that wasn’t completely clear, or gives me another set of examples to help explain it to other people. Either way they’re generally very helpful.
Post reply on HN