From my understanding, the client and the server would generate two random secrets that they would use to computer the shared key in DH for TLS. But how is this done? What algorithm does it use?
I am authenticating to my radius server using EAP-TLS v1.3 protocol. As TLSv1.3 mandates, all the certificates used are Elliptic curve (secp256-r1). However, the SSL tab of Wireshark supports only RSA Keys for now.
I want to decrypt the traffic on my supplicant (peer). Is there a way that can be done? (In a somewhat similar manner to Master Shared Secret method used for web browsers).
Any other program that can help me analyze the traffic?
Thanks in advance and apologies if I am missing something here. I am using wpa_supplicant v2.9 on peer.
i configured TLS on the mosquitto's broker as described , if i understand the real functionality of TLS :
it use both asymmetric and symmetric crypto ,asymmetric crypto for changing the key between broker/server and client and symmetric crypto to encrypt the communication between them , here i don't see where is symmetric crypto and if a type mosquitto_sub -v -u "user" -P "password" -t "path/to/topic " --cafile "path/to/ca.crt " how can i know that the communication is encrypted
I'm so confused can someone explain ???
I think you are misunderstanding how Transport Layer Security (TLS) functions. In TLS the asymmetric (public/private) encryption is used to allow two systems to agree on a form of encryption to use for communication. See the answer to this question (Which symmetric key algorithm does SSL use?) or if you are a more visual person take a look at the diagram on page 11 of this white paper (https://www.sans.org/reading-room/whitepapers/protocols/ssl-tls-beginners-guide-1029).
In your specific example, what is happening (as I understand it) is that that the Client requests an SSL connection to the Broker. The Broker and Client then use public key encryption to allow the two systems to securely agree on a form of encryption and a shared key.
I understand that through SSL, the browser gets the public key of the secured website and through public key encryption rsa algorithm, these 2 establish session key and then continue communication thru some symmetric algorithm, because symmetric key encryption/decryption is faster. Which symmetric key algorithm does SSL use? DES? AES? or something else?
When the client connects to the server, it negotiates a so-called ciphersuite (combination of encryption, key exchange, authentication algorithms) to use. Each SSL client or server has a list of allowed ciphersuites and during handshake the client and the server negotiate on what ciphersuite to use. It can happen sometimes, that there's no common denominator (ciphersuites sets don't intersect) and connection can't be established.
Symmetric algorithms supported in SSL are DES, 3DES, ARCFOUR, AES, Camellia, RC2, IDEA, SEED, NULL (no encryption).
During the connection establishment (the "handshake"), the client and server decide upon a "cipher suite" to use. The cipher suite states the algorithms which are used (asymmetric key agreement, symmetric encryption, and integrity check). In details, the client sends a list of the cipher suites it supports, and the server selects one of them, that it also supports. Normally, the server selects the first suite that it supports among those sent by the client (in other words, the ordering of the suites in the client message is its "order of preference" and the server usually honors the client preferences).
For instance, the cipher suite TLS_RSA_WITH_3DES_EDE_CBC_SHA means that the session key will be transmitted with RSA (asymmetric encryption, using the RSA public key from the server certificate), the data will be symmetrically encrypted with 3DES, and the integrity check will use the SHA-1 hash function. See the TLS specification for the list of standard cipher suites (other suites were added later on, in particular some with AES).
Several possibilities including RC4 and DES or even no encryption. Not an area I know well, but I assume client and server negotiate to find one they can both use
http://httpd.apache.org/docs/2.0/ssl/ssl_intro.html#ssl
If you are using HTTPS under Firefox, if you click the little "lock" icon in the URL bar, it will give you a pop up with the details of your connection. For example, with my server, I connect with 128 bit AES with firefox.
Different web browsers can give different results of course, since the TLS connection negotiates the connection.
How do you decrypt SSH .pcap file that uses Diffie Hellman encryption. With public and private keys.
We are trying through Wireshark with no luck.
One of the benefits of ephemeral Diffie-Hellman (the DHE ciphersuites of TLS) is that it provides perfect forward secrecy. This means that even if the private DSA key used to authenticate the server (and possibly client) are obtained by an attacker someday, she won't be able to go back and decrypt any sessions captured in the past.
In other words, you can't decrypt these captures unless you recorded the secret session key; there's no way to recover it afterward.
This is different than the RSA cipher suites, where knowledge of the server private key allows one to decrypt the session.
Because the session is encrypted by a transient "session key", having the public/private keys of the server and/or client at the end is of no use to you. Those keys are only used to verify that there has been no man-in-the-middle attack.
In order to decrypt a SSH session, you must either somehow obtain the session key (perhaps by attaching a debugger to a client on either side) or perform a man-in-the-middle attack - this requires the private key of the server (and the client, if key authentication is being used). Some more info on the latter option can be found here: http://taosecurity.blogspot.com/2007/08/loving-ssh.html
So if I understand well, the process to decrypt a SSH session is very similar to decoding wifi WPA2-PSK, you need to capture the 4-way handshake to be able to derive the transient key aka PTK. In wifi WPA2-PSK if we don't have the 4-way handshake, there is also no way to recover the transient key and decrypt the traffic even if you know the actual passphrase.