What happens behind the scenes when we type www.google.com in a browser? (2015)
github.com
github.com
He also ran teams and his leadership style was very humble and encouraging in a workplace that was, at times, the opposite.
So glad to see he's still publishing awesome content like this.
Be sure to check out some of his other popular repos, great stuff!
Now, don't get me wrong, I am not saying this is useless. I am just saying that if one chooses to give a 30k feet perspective, they had better stay there and not bounce between 40K and 10K.
Equally, in the comfort of one's own parlour, one may listen to one's wireless. Not 'consume', as was once heard.
The butler informs me on this occasion that I am correct. I bow to him in this. Uncommonly sharp fellow.
And so to the Drone's Club, where literature, wireless nor dolly birds are permitted.
I wrote something similar a couple of years ago[0] which skips the keyboard and display but goes further into the world of IP packet transmission (and HTTP/2). The parent link is better written though.
[0] https://sheep.horse/2017/10/how_you_are_reading_this_page.ht...
The server decrypts a hash? But thats not how hashes work.
Or something along those lines.
The description linked over-simplifies, the hash they're calculating is a summary of the handshake process by which keys are agreed, we want to prove that both saw the _same_ process happen to reach this state.
Suppose I am willing to use archaic method A because I'm a simpleton, although I do know methods C and E which are safer. The wise people running www.google.com only allow method A if you don't know methods B, C, D or E.
Now, I try to connect to www.google.com and unknown to me a Bad Guy is in the middle. I say "Hello, I know methods A, C and E", but the bad guy changes that message to say "Hello, I know method A only". Google replies "OK I guess we can do method A then" and we use method A. The Bad Guy knows how to break method A and now my security is ruined!
But with this Finished message in TLS, www.google.com and I will calculate different hashes, since I know I said "I know methods A, C and E" but www.google.com got a message from me saying "I know method A only" and those don't hash the same.
This proves somebody is tampering with our connection, we must abort.
Cryptographic hashes are irreversible. That's the point of such a device. But there is nothing stopping someone from taking the result of a cryptographic hash and then encrypting it, and then that someone or someone else decrypting that ciphertext to recover the hash result. E(H(S), k) leads to an encrypted hash, and D(E(H(S), k), k) recovers the hash. It's computationally infeasible to retrieve S. But nobody wanted to do that; they just wanted to know H(S).
You are correct that the server compares the result of the hash (which in context can also be called a "hash," such as "I used SHA-256 on my term paper, and then I spray-painted the hash on the face of the town clock tower, thus proving the existence of my term paper before the class deadline"). Nobody's arguing that. But how did it obtain the thing it's comparing its own result to, without M also obtaining that thing?
(I'm actually not sure whether TLS sends the actual hash or bases subsequent computations on the assumption that both sides can independently derive it. But if it does the former, it's totally fine to say "it decrypts the hash," which is the objection of the parent of this thread.)
But yes, of course you can decrypt an encrypted hash, this way you get back the plain hash.
The client calculates a hash, it _encrypts_ that hash, and sends it to the server, the server _decrypts_ it, and then can verify that it has the same calculation.
The reason this is done is that it can detect a situation in which the client and server were persuaded to arrive at the same results by different means, whereupon they should abort the connection. The mechanism in TLS 1.2 and earlier was not very good, a better one is included in TLS 1.3 but alas last I looked it is disabled in popular browsers because it's incompatible with yet more middlebox crapware from "security" companies.
It’s a good warm up question because pretty much any answer is right, and it quickly lets the candidate get to their comfort zone. It is also amenable to be simplified or tweaked - if the candidate doesn’t know much about CDNs or layer 7 load balancing or whatever, you just move past them. And you can change some of the parameters to be sure the candidate isn’t just memorizing the answer sheet.
It can also give a strong signal where the candidate’s knowledge is weak: if you talk to me at length about Apache throwing read syscalls to pull files from the disk but quickly gloss over the networking bits, that might indicate you don’t know them well.
A good candidate had breadth and depth of knowledge. This one question shows breadth and tells you where to find depth. It doesn't work as well for pure frontend people, but only barely - I almost expect frontend people to understand interrupts and syscalls on that end.
I usually try to focus on what the interviewer wants me to demonstrate knowledge on when I answer the question in an interview. As an interviewer I normally avoid the question and make it more job specific. I might ask about troubleshooting slow servers based upon an incident and try to determine the candidate’s thinking pattern and methodology. For developers it’s easier to ask “this block of code is not doing what I expected, what did I do wrong?” where the mistake is a very common one. I actually had a very practical HackerRank problem that asked me to troubleshoot a program and an accompanying docker compose file. If you had prior experience this would take you 2 minutes while you wonder if that’s really the whole problem.
If you do use it, you’re merely selecting for people who have read posts like this on HN and reddit. Candidates who have memorized any of this will look vastly superior to those who haven’t.
It’s telling that there are already two sibling comments who are arguing that this is a good question - explains a lot about why technical interviews suck.
I'm not an employer but I know I'd rather my workmates were the kind of people who are actually interested in computers enough to read about them for pleasure, not just those "straight by the book" types.
If they don't give a good answer, maybe they haven't looked into networking details and debugging for some reason -- a lot of junior people haven't, but they may have the aptitude to learn and be great at it, but just don't have the knowledge base yet. Although it depends on exactly what you're hiring for, too. If you need the person like me, who will find and fix your weird problems with networking, maybe they should know this, or be able to make fairly plausible guesses; but most people on my team don't need to do that (although it's always nice to have more).
What is the difference? If they studied it, they now know?
Is it because as an interviewer, you are looking for knowledge by experience, not via book-learning?
I guess if you stop at each point and ask 'what could go wrong here, and how would you debug it' and they answer that well, then they've gotten the information enough.
What you’re doing here is arguing a truism: any candidate who memorizes the answer to the shibboleth is better than the ones who don’t, because it makes you happier that they memorized the shibboleth.
But I’m still doing them and my employer won’t let me stop - so help me refine a bit. What question(s) would you like to see interviews ask more?
Kidding. Don’t listen to the parent. The only problem with this question is that it’s general purpose and very well understood, but those aren’t issues. You should still ask people what port HTTPS uses even if it seems stupid because you’re going into an interview blind and you need to assess the experience of a person very quickly (and, sometimes you get surprised by charismatic fools). All questions are tools, this one will tell you that either the person knows this question very well from studying it (which is valid, and you would be able to tell) or they have some experience with it (more valid) but it will tell you where they are most comfortable talking about and you can dig more into various parts if you want.
The question is good because it both involves something most everyone does on a daily basis while providing a wide range of possible areas to explore further: there isn't any single "correct" answer that's possible to cover in a short time, but what candidates do tell you probably indicates what they're most familiar with.
Candidates prepping for this question isn't much of an issue since (a) most simply don't and (b) there's always room to go further into a specific part of the transaction.
How about this: ask questions relevant to the job. Stop trying to be clever.
This is usually one of the three questions I require as part of an application.
The other two are a technical question tailored for the position and the third a 'throwaway' that the applicant answer as they see fit. In the past it's been things like "What is the airspeed of an unladen swallow? (European or African)"
What are you expecting to get from something like that?
In any case, it's a chance to show themselves as a person.
in my version, it’s not “what is behind the scenes “, it’s “tell me everything you can in as much detail as you like, what has to happen to visit www.google.com”. of course in 2009 google had only just become google.com.
I was interviewed on this in 2004 for Yahoo! although the hostname in question was different.