Thanks for the article, Ali!
By this
"6. The client sends a finished message encrypted with the session key. Then the server sends a finished message too, encrypted with the session key.
If any of these steps fail (including the validation algorithm below) the connection is aborted."
are you saying that if an attacker sent a forged message, they can close a perfectly legitimate established SSL connection? That is, let's say I know that there is an SSL connection someone is using for accessing their bank account. If I send just one forged message, it will abort their connection. Is that right?
If an attacker can intercept the public key of the certificate, then they can send spoofed messages to the client pretending that they are the server (man-in-the-middle attack). An attacker would have to make their own socket with their IP address and port in order to do that. That how they can trick the client in the first place. It only needs the public key (EDIT: and private key). In practice this doesn't happen with newer SSL versions, especially TLS 1.3, because they use strong ciphers.
In the post when I said "the connection is aborted", I should have made it clear that only browsers do that. For example, the SSL errors you see in Chrome are a manifestation of this.
Thanks for the article, Ali!
By this
"6. The client sends a finished message encrypted with the session key. Then the server sends a finished message too, encrypted with the session key.
If any of these steps fail (including the validation algorithm below) the connection is aborted."
are you saying that if an attacker sent a forged message, they can close a perfectly legitimate established SSL connection? That is, let's say I know that there is an SSL connection someone is using for accessing their bank account. If I send just one forged message, it will abort their connection. Is that right?
Hi there,
A forged message will not abort the connection.
If an attacker can intercept the public key of the certificate, then they can send spoofed messages to the client pretending that they are the server (man-in-the-middle attack). An attacker would have to make their own socket with their IP address and port in order to do that. That how they can trick the client in the first place. It only needs the public key (EDIT: and private key). In practice this doesn't happen with newer SSL versions, especially TLS 1.3, because they use strong ciphers.
In the post when I said "the connection is aborted", I should have made it clear that only browsers do that. For example, the SSL errors you see in Chrome are a manifestation of this.
Isn't the public key of the certificate findable by anyone?
Yeah, sooner I realized this and I meant to say public key and private key, but I was out sick the past few days so I couldn't edit my articles.