I have some HTTPS/SSL packets between client and the server. I need to decrypt the application data after the SSL handshake. I have a SSL server key as well. I configured wireshark to take the private key like shown below.
I went to EDIT-> Preferences-> protocols->SSL -> Add private key to RSA key list.
I have a JKS keystore configured on the server and I converted it to PKCS format and gave in wireshark. But still I am not able to decrypt the data . Please help
Related
I have traffic between clients (which send XML over HTTPS) to my IIS.
I tried to decrypt the traffic using Wireshark and the following settings:
Adding the private key:
But even after setting this, I can't see the decrypted data:
Should I change any other settings to see the original data?
There is strong possibility that a Diffie-Hellman (DH) key exchange is being used here. In that case Wireshark cannot decipher SSL/TLs with a private key. You can check for this in the handshake packet.
From the Docs:
The RSA private key file can only be used in the following
circumstances:
The cipher suite selected by the server is not using (EC)DHE.
The protocol version is SSLv3, (D)TLS 1.0-1.2. It does not work with TLS 1.3.
The private key matches the server certificate. It does not work with the client certificate, nor the Certificate Authority (CA)
certificate.
The session has not been resumed. The handshake must include the ClientKeyExchange handshake message.
In most of the online sources, I was told that in the two way TLS,
the client needs to provide the cert for the server to validate. My
case is that the device gets the cert from the CA, but when the
device attempt establish a tls connection, the pfx is required which
will contain the private key from the device.
I have used openssl to convert the pfx to .cert and .key. By only using the .cert part on
POSTMAN, I failed to connect to the server with 403. Only when I
include both .key and .cert the TLS 1.2 connection was established.
For the regular TLS (one-way), the private key will never be sent
from the server, but why is the client need to send pfx.
I have a flask application(client) from where I need to send some data to a server(another flask application as of now) and get some corresponding data. I need to use REST because the server can be anything later(the current flask app is a dummy server for testing). I need to have SSL connection between client and server. I see that SSL works in several steps:
Client requests for an encrypted connection.
Server responds with an SSL Certificate which will have a public key.
Client verifies the SSL Certificate
Client creates a private key
Client encrypts the private key with the public key and sends it to the server.
Server decrypts it and gets the private key.
Thus an encrypted connection is established between client and server. Further exchange of data between client and server happens by encrypting the data with the private key.
This is what I am trying to achieve. Please correct me if I got the SSL concept wrong.
I have seen below implementation and works perfectly for me.
Client side uses requests.get() with verify=<path to server SSL certificate>. I have generated SSL certificate for server using openssl as follows.
openssl req -x509 -newkey rsa:4096 -nodes -out cert.pem -keyout key.pem -days 365
But I don't think all the above 7 steps are being covered here. What is the actual way of implementing SSL? Any help would be appreciated.
Client requests for an encrypted connection.
Correct.
Server responds with an SSL Certificate which will have a public key.
Correct.
Client verifies the SSL Certificate
Correct.
Client creates a private key
Incorrect. It is already far too late for this to occur.
Client encrypts the private key with the public key and sends it to the server.
Incorrect. There is no such step. See RFC 2246 and successors.
Server decrypts it and gets the private key.
Incorrect, ditto.
Thus an encrypted connection is established between client and server.
Incorrect, ditto.
Further exchange of data between client and server happens by encrypting the data with the private key.
Incorrect, ditto. TLS works by (1) establishing trust via the server certificate and PKI; (2) optionally establishing trust via the client certificate; and (3) establishing a symmetric session key via a process of key negotiation, in which the actual session key is never transmitted.
This is what I am trying to achieve.
No it isn't. You are trying to establish a TLS connection. What it does is really very little concern of yours.
Please correct me if I got the SSL concept wrong.
You got it totally wrong.
I have generated SSL certificate for server using openssl as follows.
No you haven't. You have created a Certificate Signing Request (CSR). This is useless until you get it signed by a Certificate Authority (CA). It isn't an SSL certificate.
In the above method of implementation, client verifies the server's certificate for every rest call but I dont want to do this. I want to create an encrypted connection between client and server and then the further exchange of data should be encrypted. So, I think the initial creation of enrypted connection between client and server is missing. Also, the private key generation from client side is missing. I want to implement SSL and I think TLS is different from SSL. Correct me if I am wrong.
You are wrong. TLS supports session resumption, which allows for abbreviated handshakes, which eliminates the certificate exchange steps. The 'private key generation from client side' step is missing because it doesn't necessarily exist. You're guessing.
When we ssh to a host, he is either known or not. In the latter case during our first try to connect we are prompted to
The authenticity of host '13x.8x.xx.1x1 (13x.8x.xx.1x1)' can't be established.
RSA key fingerprint is xx:xx:xx:xx:xx:26:86:80:5f:17:xx:xx:xx:xx:6d:6c.
Are you sure you want to continue connecting (yes/no)? yes
Then the server's RSA public Key is stored in the .ssh/know_hosts file. How is it encoded? And how can we ensure that this is not a man-in-the-middle?
Finally, this so-called 'host key' is assymetric. What does this mean?
How can we ensure this is not a man-in-the-middle?
The first time, you can check the RSA fingerprint. Someone needs to previously communicate it to you, or you need to somehow receive it securely (ie published via a https site, or received via a signed email). Many hosting providers, for example, send you your hosts SSH fingerprint.
On Ubuntu, you can find your own RSA fingerprint using:
ssh-keygen -lf /etc/ssh/ssh_host_rsa_key.pub
Note that there are other in-use fingerprint formats (dsa and ecdsa), depending on the server and client config. In your known_hosts file you can see the format in which each fingerprint has been stored.
How is it encoded?
The known_hosts file is a list of hostnames (or often, hashes of hostnames), the type of the fingerprint, and the fingerprint itself (cryptographic information) in base64 encoding. The format details can be found in the OpenSSH man page, under the SSH_KNOWN_HOSTS FILE FORMAT section.
This so-called 'host key' is asymmetric. What does this mean?
These asymmetric mechanisms mean that while the fingerprint allows you to verify the identity of the server, you cannot use it to generate a valid identification (to impersonate) that server.
It must be noted that the fingerprint (and the corresponding private key) are used as secret for cryptographic operations: a random challenge is sent from the client to the server. The server, which has the private key, can sign that challengue and send it back, then the client can verify the signature is valid because the fingerprint is appropriate.
In other words, the cryptographic secret is two-fold, the private key can cipher or sign, and the public key can be used to decipher or verify a signature. One of the keys can be made public at no risk, and used to verify signatures and to cipher text that only the owner of the private key will be able to decode. This is roughly what asymmetric means in cryptography.
As I understand the working of digital certificates:
1. The server generates public and private key
2. It then generates a CSR and submits it to the CA
3. The CA signs it with its private key and returns the certificate to server
While sending data to server:
1. Encrypt the data using server's public key and transmit. Only server will be able to decrypt it as it has the private key
While downloading data from server:
1. The server encrypts the data using its private key. It trasmits the certificate and the data.
2. User decrypts the certificate using CA's public key.
3. Then decrypts the data using the public key obtained from decrypted certificate.
I think what server needs is only private key and the certificate issued by CA
Client needs is CA public key
What I don't understand is the server config too has an option of specifying CA cert file path. Will this ever be used if we are talking about server only security that is the client is not using its own keys ? Is that a mandatory parameter for server config with SSL/TLS ?
I hope I am making sense
While sending data to server: 1. Encrypt the data using server's
public key and transmit. Only server will be able to decrypt it as it
has the private key
While downloading data from server: 1. The server encrypts the data
using its private key. It trasmits the certificate and the data. 2.
User decrypts the certificate using CA's public key. 3. Then decrypts
the data using the public key obtained from decrypted certificate.
That's completely wrong (remember, you don't actually encrypt with a private key). That's not at all how SSL works. A new symmetric key is generated for the encryption, per session. See this question for more details.
The CA certificate is used as a trust anchor to verify the identity of the remote party.
Strictly speaking the server itself doesn't need to have a copy of the CA used to sign its own certificate, since it's up to the remote party (the client) to have it as a trust anchor (i.e. something it already trusts).
Nevertheless, it can send the CA certificate as part of its server chain. It is in fact recommended to do so if the CA certificate is itself signed using another CA certificate up the chain. Doing so increases the chances of being authenticated by the remote party.
Servers generally can have options to specify the CA cert for two reasons (depending on what the option is):
Presenting their own certificate chain (i.e. with intermediate CA certificates).
Verifying the client certificate when used (in this case the server has its own trust anchors that lets it verify the remote certificate, which is the client certificate).