03-13-2012 08:57 AM - edited 03-17-2019 10:55 PM
Hi,
how does TLS exactly work when not using certificates?
For example when an E20 registers with the VCS having default transport set to TLS.
Kind regards
Maciek
03-13-2012 09:52 AM
First of all the VCS has a default server certificate, you can find it here:
https://
About the TLS handshake you can find more on the net, like wikipedia:
http://en.wikipedia.org/wiki/Transport_Layer_Security#Simple_TLS_handshake
Client-authenticated TLS handshake
The following full example shows a client being authenticated (in addition to the server like above) via TLS using certificates exchanged between both peers.
- Negotiation Phase:
- A client sends a ClientHello message specifying the highest TLS protocol version it supports, a random number, a list of suggested cipher suites and compression methods.
- The server responds with a ServerHello message, containing the chosen protocol version, a random number, cipher suite and compression method from the choices offered by the client. The server may also send a session id as part of the message to perform a resumed handshake.
- The server sends its Certificate message (depending on the selected cipher suite, this may be omitted by the server).[31]
- The server requests a certificate from the client, so that the connection can be mutually authenticated, using a CertificateRequest message.
- The server sends a ServerHelloDone message, indicating it is done with handshake negotiation.
- The client responds with a Certificate message, which contains the client's certificate.
- The client sends a ClientKeyExchange message, which may contain a PreMasterSecret, public key, or nothing. (Again, this depends on the selected cipher.) This PreMasterSecret is encrypted using the public key of the server certificate.
- The client sends a CertificateVerify message, which is a signature over the previous handshake messages using the client's certificate's private key. This signature can be verified by using the client's certificate's public key. This lets the server know that the client has access to the private key of the certificate and thus owns the certificate.
- The client and server then use the random numbers and PreMasterSecret to compute a common secret, called the "master secret". All other key data for this connection is derived from this master secret (and the client- and server-generated random values), which is passed through a carefully designed pseudorandom function.
- The client now sends a ChangeCipherSpec record, essentially telling the server, "Everything I tell you from now on will be authenticated (and encrypted if encryption was negotiated)." The ChangeCipherSpec is itself a record-level protocol and has type 20 and not 22.
- Finally, the client sends an encrypted Finished message, containing a hash and MAC over the previous handshake messages.
- The server will attempt to decrypt the client's Finished message and verify the hash and MAC. If the decryption or verification fails, the handshake is considered to have failed and the connection should be torn down.
- Finally, the server sends a ChangeCipherSpec, telling the client, "Everything I tell you from now on will be authenticated (and encrypted if encryption was negotiated)."
- The server sends its own encrypted Finished message.
- The client performs the same decryption and verification.
- Application phase: at this point, the "handshake" is complete and the application protocol is enabled, with content type of 23. Application messages exchanged between client and server will also be encrypted exactly like in their Finished message. The application will never again return TLS encryption information without a type 32 apology.
Please remember to rate helpful responses and identify
03-14-2012 01:21 AM
Hi Martin,
I'm talking about a situation when not using certificates.
From the E20 admin guide: "If no such CA-list is available on the system then anonymous Diffie Hellman will be used.". So also having TLS Verify set to Off means that you're not using certificates. At least that is my understanding.
Kind regards
Maciek
03-14-2012 10:26 AM
http://lmgtfy.com/?q=anonymous+Diffie+Hellman+tls+key+exchange&l=1
F.1.1.1. Anonymous key exchange
Completely anonymous sessions can be established using RSA or Diffie-Hellman for key exchange. With anonymous RSA, the client encrypts a pre_master_secret with the server's uncertified public key extracted from the server key exchange message. The result is sent in a client key exchange message. Since eavesdroppers do not know the server's private key, it will be infeasible for them to decode the pre_master_secret. (Note that no anonymous RSA Cipher Suites are defined in this document).
With Diffie-Hellman, the server's public parameters are contained in the server key exchange message and the client's are sent in the client key exchange message. Eavesdroppers who do not know the private values should not be able to find the Diffie-Hellman result (i.e. the pre_master_secret).
Warning: | Completely anonymous connections only provide protection against passive eavesdropping. Unless an independent tamper- proof channel is used to verify that the finished messages were not replaced by an attacker, server authentication is required in environments where active man-in-the-middle attacks are a concern. |
Please remember to rate helpful responses and identify
03-14-2012 01:56 PM
No need to be rude Martin. I have found the answer myself, the earlier post provided it and explained what I meant as your previous answer had nothing to do with the question asked.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide