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

21–30 of 36 posts

Re: Mediocre Engineer's Guide to HTTPS

#21

Post by jessriedel »

treflop wrote: post #16
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’…

If Google dedicated 10 engineers full time to this problem for 3 years, could they solve it?

Re: Mediocre Engineer's Guide to HTTPS

#22

Post by AlienRobot »

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…

How are you trying to tell that?

If a web browser can't access a URL, it won't tell you why exactly because there's a chance it diagnosis the reason wrong and most users will be confused by that. I assume most diagnosis tools work the same way. You need to make assumptions about how the OS, hardware, and network are configured to be able to say "the problem is here."

For example, when you access a website, the first thing that needs to be done is check a domain name server (DNS) to get the IP address of the web server. But where does the web browser get the DNS IPs from? You can configure it in the browser. Or in the OS. Or in your router. Or in your modem. And if you don't, it gets them from the DHCP server the router connects to, which could be your ISP's DHCP server (then you get your ISP's default DNS) or it could also be some other router in an organization's network.

If the DNS seems wrong it's easy to tell the IP is wrong but it gets hard to say where that IP came from.

Even SSL could be a problem with the server having the wrong certificates or it could be your computer having the wrong certificates.

Re: Mediocre Engineer's Guide to HTTPS

#23

Post by _ache_ »

recursive wrote: post #6
_ache_ wrote: post #5

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

I said 30% of the requests on the web use HTTP3. And now a day CORS and other mechanisms that are not cited in the articles.

Re: Mediocre Engineer's Guide to HTTPS

#24

Post by awesomeMilou »

jessriedel wrote: post #21
treflop wrote: post #16

Earlier quoted context omitted.

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

If Google dedicated 10 engineers full time to this problem for 3 years, could they solve it?

Yes, and they partially have. Browsers are great at telling you where the chain has failed/ been cut, though some error messages seem to be intentionally uninformative as provided information would be meaningless to your average user.

That said, from an enthusiast perspective, running traceroute to the nearest google service (1e100.net for example) will already give you a huge tip on where things went wrong.

Re: Mediocre Engineer's Guide to HTTPS

#25

Post by deathanatos »

> By agreeing on all these algorithms, exchanging random seeds, and the server’s SSL certificate containing the private key;

I sure hope not. But I suppose it is titled "Mediocre Engineer".

> $300K/year

… I'll undercut you by $50k/y; where do I apply?

(There are just more and more errors. TLS 1.3) do not support RSA" …

… these sorts of blogspam are why I wish sometimes that there was a downvote. The advert isn't so obnoxious as to make me want to flag is low enough. I guess I should write the less mediocre article and make the HN frontpage. If only I made $300K/y, I'd have more time.)

Re: Mediocre Engineer's Guide to HTTPS

#26

Post by otabdeveloper4 »

jessriedel wrote: post #21
treflop wrote: post #16

Earlier quoted context omitted.

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

If Google dedicated 10 engineers full time to this problem for 3 years, could they solve it?

As long as you only ever visit Google web properties, yes.

Re: Mediocre Engineer's Guide to HTTPS

#27

Post by m1keil »

jonwest wrote: post #19

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.

This article is largely feels like a 3 to 4 Cloudflare blog/articles summarisation. If you want more of this stuff, check CF's learning centre: https://www.cloudflare.com/learning/

Examples: https://www.cloudflare.com/learning/dns/what-is-dns/ https://www.cloudflare.com/learning/ssl/transport-layer-secu... https://www.cloudflare.com/learning/performance/what-is-http...

Re: Mediocre Engineer's Guide to HTTPS

#28

Post by pietrod »

I'm unable to find some code where it shows how to verify the signature of SHA256(client_hello_random + server_hello_random + curve_info + public_key) I know the theory but somehow there is some issue to implement it, anybody can link an actual toy program showing practically how to do this?

Re: Mediocre Engineer's Guide to HTTPS

#29

Post by boffinAudio »

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…

Cyclomatic Complexity is why your Operating System can't do this for you.

https://en.wikipedia.org/wiki/Cyclomatic_complexity

There are so many different paths for an error case to follow.

You can of course debug this by reducing the complexity - for example, by watching one of the links in the chain (say, DNS) and seeing if it is failing - but this is the realm of network engineers who get paid mightily to get through this cyclomatic complexity and work at the relevant layers, all the way down to the atoms in the pipe ..

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

In fact, the links all do this, but there is simply no provision in your OS - no fancy GUI, perhaps - that allows you to fully understand this without getting overwhelmed by the cyclomatic complexity. Tools exist, and once you learn to use them to tame the complexity - congrats, you're now worth $300k/yr and can go work in San Francisco .. /s ;)

Re: Mediocre Engineer's Guide to HTTPS

#30

Post by raxxorraxor »

> Current version of TLS (>1.3) do not support RSA (and various other cipher suites) for security reasons.

That is true for the key exchange part because RSA does not offer forward security. For signatures RSA is still used and probably still the most widely spread type of x509 certs.

I know Safari just upped the requirements to 2048bit keys for RSA not too long ago (for signatures).

Post reply on HN