0

As far as I know, the SSL certificate is public and anyone can read it. Is it possible in this case, for example, when someone, having copied the SSL certificate of my bank for himself, will be able to deceive me, acting as an man in the middle?

John
  • 9
  • 2
  • Related: https://security.stackexchange.com/questions/105376/could-a-stolen-certificate-show-as-trusted – mti2935 Apr 25 '22 at 14:56
  • 1
    @mti2935 I read this topic but don`t fully understand, why in this case TLS connection will be failed. What role does the server's private key play in setting up a TLS handshake? – John Apr 25 '22 at 15:10
  • 1
    @mti2935 Note: my question about DH algorithm for key exchange, not RSA. I agree in RSA case, server's private key used for decrypt pre-master secret key which client send to server. But what about for DH key exchange algorithm? What role does the server's private key play in setting up a TLS handshake? – John Apr 25 '22 at 15:21
  • OP, See https://security.stackexchange.com/questions/105485/using-a-stolen-certificate-on-a-server – mti2935 Apr 25 '22 at 15:23
  • Does this answer your question? [Using a stolen certificate on a server](https://security.stackexchange.com/questions/105485/using-a-stolen-certificate-on-a-server) – foreverska Apr 25 '22 at 15:29
  • 1
    @mti2935 Thank you. In second topic, you are say "If DH is used, the server uses its private key to create a digital signature, which the client then verifies using the server's public key from the server's certificate". What does this signature look like? What exactly does the server sign with its private key if the DH algorithm is used? – John Apr 25 '22 at 16:01
  • 1
    @mti2935 i found "The client and the server generate a set of ephemeral ECDHE keys that are used to facilitate the secure session" in your post. Thank you very much! – John Apr 25 '22 at 16:07
  • OP, glad it helped. See https://tlseminar.github.io/first-few-milliseconds/ for a deeper dive of how it's done in TLS1.2. The part you are interested in is ServerKeyExchange. – mti2935 Apr 25 '22 at 16:09
  • 1
    @mti2935 thank you again! – John Apr 25 '22 at 16:10
  • OP, If you just receive a public key from the server (without the public key contained in certificate signed by a CA), then how do you know that the public key is really the server's, and not a man in the middle? See https://en.wikipedia.org/wiki/Man-in-the-middle_attack for more info on this type of attack (known as a 'MITM' attack). This is why we have certificate authorities (CA's), that we trust to authenticate that certificates do in fact belong to their purported owners. – mti2935 Apr 25 '22 at 16:25
  • @mti2935 thank you! :) – John Apr 25 '22 at 16:31
  • @mti2935 I need to encrypt the traffic that is sent over UDP. Is it possible to close the connection after the completion of the TLS handshake and use the received shared key for data exchange via the UDP protocol? If yes, how safe is it? – John Apr 25 '22 at 16:49
  • OP, I'm not sure how this would work in a browser scenario. Browsers and servers don't make it easy to get to the ephemeral session keys. Then, even if you can get to these, it sounds like you would be rolling your own protocol at the application layer. As another option, you might want to look into DTLS (which is basically TLS over UDP) or https over UDP. See https://stackoverflow.com/questions/15331294/difference-between-dtls-and-tls and https://security.stackexchange.com/questions/75911/is-https-over-udp-secure for more info. – mti2935 Apr 25 '22 at 17:03
  • @mti2935 thanks for answer! my case is not browser scenario :) – John Apr 25 '22 at 17:46
  • @mti2935 do you know how i can implement that using openssl library in c/c++? – John Apr 25 '22 at 17:48
  • Thinking about this a little more - what might work well is for the client to establish a TLS connection to the server (over HTTPS), then have the client create a random ephemeral key, and send this to the server of the TLS connection. Then, the UDP packets sent between the client and the server (in both directions) during the session can be encrypted with a symmetric cipher, such as AES-GCM. This avoids the problem have having to pluck out the TLS session keys on both the client and the server. – mti2935 Apr 25 '22 at 17:57
  • Also, I've worked with C/C++ and I've worked with openssl, but I've never worked with the openssl libraries in C/C++. Having said that, you might want to take a look at Erwin Hoffmann's ucspi-ssl tools (at https://www.fehcom.de/ipnet/ucspi-ssl.html) which make it simple to create TLS clients and servers. Also see https://github.com/meixler/installing-configuring-and-running-ucspi-ssl-sslserver. – mti2935 Apr 25 '22 at 18:03
  • @mti2935 thank you for useful advices! – John Apr 25 '22 at 18:26
  • Please edit the question to add the missing information from the comments. – Sir Muffington Apr 25 '22 at 19:53

0 Answers0