Comments by "Lawrence D’Oliveiro" (@lawrencedoliveiro9104) on "ByteByteGo" channel.

  1.  @alexandermiasoiedov6637  TLS is resistant to MITM attacks, because key-pair encryption ensures that what is encrypted at one end can only be decrypted at the other end.
    7
  2. The client has a list of CA certs that it trusts, so it will accept any server cert that is signed by one of them. TLS can also be used for two-way authentication. Also for secure communication between different parts of your own organization, you can create your own CA cert and install that at the endpoints so they can trust each other.
    6
  3. Easy enough for browser to expire their connection IDs and negotiate new ones say, every 15 minutes.
    6
  4. 0:17 There was an HTTP/0.9, which left out some of the header structure. I think it was very quickly replaced with HTTP/1.0, which regularized the whole request/response structure.
    3
  5. Cryptographic hashes are fast enough to run, say, millions of times per second. For password hashes, you want to slow that down to something more like a thousand times per second. That still makes no perceptible difference to a human user logging in, but it will throw a real spanner in the works of brute-force password-guessing systems. By the way, password hashing is useless if you want to do shared-secret authentication, where it’s not just the client authenticating to the server, but the server is also authenticating to the client. For that, you cannot avoid storing plain-text passwords on the server.
    2
  6. To ensure that the server you are connecting to is really who they say they are.
    1
  7. I wonder why Google didn’t use SCTP for HTTP/3 ... is it because too many existing internet routers only understand TCP and UDP, and nothing else? By the way, no one seems to have mentioned that the original name for HTTP/2 was “SPDY” ... ”SPDY”, then “QUIC” ... geddit?
    1
  8. There is no way to store a secret on the server in such a way that an attacker who gets hold of that secret is not able to masquerade as that server.
    1
  9. Encryption really just adds processing time at the endpoints, which should be minimal overhead on today’s fast CPUs. In terms of protocol bandwidth overhead, it shouldn’t be large.
    1
  10. HTTP is an application (layer-7) protocol, TCP is a transport (layer-4) protocol.
    1
  11. The *nix shadow file does exactly that -- the password hash begins with a prefix indicating which algorithm was used.
    1
  12. You don’t. You do a password “reset”, which means a new password is assigned.
    1
  13. All that does is apply one level of hash to the client-entered password, and store that as the “real” password. Anybody who gets hold of that hash cannot impersonate the client, but they can impersonate the server.
    1
  14.  @nicoflaig6749  Diffie-Hellman isn’t an authentication protocol.
    1
  15.  @nicoflaig6749  It can’t be “zero knowledge” if you have to know the password, can it?
    1
  16.  @nicoflaig6749  So “zero” doesn”t mean “zero”, it actually means “one”? In programming, we call that an “off-by-one error”.
    1
  17.  @nicoflaig6749  Don’t know, don’t care about any videos. Instead, I read RFC2945, which is where SRP is defined. I draw your attention to section 3, where it is specified that the host stores the triple “{ <username>, <password verifier>, <salt> }”. That “password verifier” is the hash I was talking about. Anybody who gets hold of that information can impersonate the host.
    1
  18. True, but with Open Source, you can just take an existing server or client program (or set of libraries) as the basis for your project, instead of having to reinvent everything from scratch. For example, Python offers loads of toolkits for things like TLS, WebSockets etc that you can reuse. The problem with coming up with your own implementation of some standard protocol is getting it wrong. We saw this a lot with proprietary SMTP, HTTP and DNS products in the 1990s, just for example. Luckily all of them are extinct now.
    1
  19. Seems like the answer is “for as long as necessary”. As far as I can tell, in TLS 1.3 they don’t see any point in forcing expiry of any session keys before they have to -- there is no security gain in doing so.
    1
  20. HTTP cannot switch to TLS encryption until the Server Name Indication (SNI) has been sent. Then, based on the host name that was specified, the appropriate certificate can be selected for the encryption. Because the host name has to be sent in the clear, this can be seen as a security vulnerability. This why we have proposals for Encrypted SNI. But what encryption key do you use to send this? That encryption key is taken from the DNS. This requires a secure DNS. And there are two different proposals for that. Which is a whole other story.
    1