I am planning to manually edit the file squid.conf to disable DH key exchange in tls cipher suite of squid proxy. But first I can not change file squid.conf because pfsense always overrides it after reboot, and the second I don't know how to disable DH key exchange to use RSA instead for all cipher suite in TLSv1.2
Related
I'm investigating possibility to offload SSL to GCP Cloud KMS.
If we look at a guide https://cloud.google.com/kms/docs/reference/pkcs11-nginx we can see that asymmetric-signing key is created in KMS.
gcloud kms keys create nginx-key --keyring "KEYRING" --project "PROJECT" \
--location "LOCATION" --purpose "asymmetric-signing" \
--default-algorithm "ec-sign-p256-sha256" --protection-level "hsm"
Then this signing key is used in NGINX:
ssl_certificate "/etc/ssl/nginx/ca.cert";
ssl_certificate_key "engine:pkcs11:pkcs11:object=nginx-key";
The questing is how decryption is done in SSL flow if we use only signing key that can't do decryption?
Thanks!
As can be seen ecliptic curve signing is used. So, there is no decryption of symmetric secret during SSL handshake because Diffie–Hellman key exchange schema is used.
A ephermeral session key is established during the SSL handshake and that key is used for the encryption of messages between the client and server. The KMS key is used durting the handshake to prove (via signing) to the client that they are connected to the correct server.
I have a strange question, and I don't even know how to phrase it, but I try my best
I use laravel forge to manage my SSL with LetsEncrypt.
It generates the files:
server.crt
server.key
How to get .pem file from .key and .crt files?
based on that link, I understood the server.crt is the same as the .pem the poster was asking about.
So, to generate the ca.pem I did the following:
cat /etc/ssl/certs/DST_Root_CA_X3.pem server.crt > ca.pem
then in my nginx.conf I have these lines:
ssl_client_certificate /etc/nginx/ssl/domain/ca.pem;
ssl_verify_client on;
My main goal is to use it with mqtt, and following 2 guides, I reached this setup, but sending the ca.pem with my mqtt command, I get:
*77 client sent no required SSL certificate while SSL handshaking, client: 11.112.7.84, server: 11.166.22.84:8883
This won't work.
You need to use your own CA to issue client certificates, you can't use LetsEncrypt's CA and Server certificate to issue/verify the client certificates (they should have the flags set to make this impossible).
ssl_client_certificate needs to point to the certificate chain used to issue the client certificates that the client presents to identify it's self.
The certificate used to verify broker doesn't need to be related to the client certificates in any way.
I could find any quick answer on google. Most probably the answer lies somewhere in RFC docs on http or https however I just couldn't (too time consuming ) get those information.
So here is the question:
Is the content of a webpage served through HTTP signed digitally by the server ? Same question for HTTPS.
If yes, how does it work correctly when using a proxy ? In my opinion the proxy could tamper the data, sign the tampered data with it's own private key, and claim that the corresponding proxy's public key is actually the genuine public key of the original server ? I am assuming that the client can't check the original server's public key, because there is a proxy which could lie.
I am sorry if this is a dump question and easy searchable on the internet, but every answer I found posed some doubts to me.
Thanks for your help :)
Content sent via HTTPS is encrypted, clients verify the authenticity of the host certificates with whom they are communicating. The server uses a TLS/SSL key/certificate which is signed by certificate authorities (CA) The CAs make sure that they only sign the certificates of the rightful owners of a domain. The certificates of the CAs them-self are installed in you browser/OS. By using these pre-installed certificates, the browser can check if the key used by the remote server is signed by a trusted CA.
A man-in-the-middle does not have the original key, nor another key signed by a CA for the domain in question. Therefore, a man-in-the-middle cannot modify the content without breaking HTTPS.
On the other hand, if you want to use a proxy to cache requests, the proxy can terminate the HTTPS connections. This means the proxy has its own connection to the server and verifies the certificates. In order to secure the connection to the client, the proxy acts as a CA and uses a HTTPS connection with self-signed certificates. To avoid that your browser complains about an insecure connection, you need to install the proxies own CA certificate.
HTTP content is not signed and can be tampered with.
Edit 2018-06-15:
I wasn't really precise with the term "signed" here. The server does not actually sign the content it sends. This means if you store the responses from the server, you cannot prove that they came from that server, in other words: standard TLS dose not provide non-repudiation. However, the authenticity of the server is established during the handshake. The client encrypts a master-key with the servers public key. Only servers in possession of the private key can decrypt the master-key and derive session keys from them.
CAs, on the other hand, actually sign the certificates. A CA cannot validly deny that it signed for the authenticity of a server certificate.
Does an SSL server randomly generate a temporary key pair for every client that connects?
I understand how public-key encryption works -- public encryption key, secret decryption key. That explains how a host with an SSL certificate can receive encrypted data from a client. But how does an SSL server send encrypted data back to the client?
(There was a discussion on this topic in this question, although it was edited a number of times, so it may be confusing.)
The public key in the server certificate is only used during the handshake.
During the handshake, the client and server negotiate a secret shared key (a new one for each session) that they use for the actual encryption.
How this secret is negotiated depends on the cipher suite: RSA or Diffie-Hellman key exchange. When using RSA key exchange, the client encrypts the pre-master-secret and sends it to the server (who is the only one able to decrypt it). When using DH, the client verifies the signature of the temporary parameters sent by the server during the DH exchange: the end result is also a shared pre-master-secret. This is then used with the exchanged random values by both parties to compute the master secret.
There are more details in the TLS specification section called "Handshake Protocol Overview".
how can i debug/decrypt the data of a ssl connection (not https) when having a tcpdump file from the first time connecting until the end? is this possible?
Thanks,
Thomas
Wireshark can do this if you have the server's private key and if the cipher suite allows it (Ephemeral Diffie-Hellman suites won't work, for example).