My team is writing an app which has persisted connections which are encrypted using SSL (On Windows Server). These are CA signed certificates. The CA is in our Corporate Network so controlled by the domain, but I dont think its relevant to the question.
I see that if I remove the underlying certificate from cert store (certlm.msc) the connections which were already established continue to stay alive and not teared down. Aren't these SSL connections suppose to tear down if the certificate is removed ?
This is on a Windows Server 2016.
see that if I remove the underlying certificate from cert store (certlm.msc) the connections which were already established continue to stay alive and not teared down. Aren't these SSL connections suppose to tear down if the certificate is removed ?
No. The connections exist; the handshake is complete; there is no reason why the connection should monitor the state of the certificate store. Until the next handshake.
Related
TLS handshake for some websites is really slow. (Let it be www.example.com) (I don't own the website)
I was thinking if I could self sign certificate for www.example.com, this could speed up the process (something similar to --no-check-certificate in wget)
PS: I'm aware of the potential security risks associated.
You cannot directly provide your own certificate for the TLS handshake with a website you don't control.
But you might have some SSL intercepting proxy where the connection between this MITM proxy and the client is authenticated by your custom certificate. Only, the connection between the proxy and the server is still authenticated by the servers original certificate, so you've likely just moved the slow handshake problem from your client to your proxy but will be ultimately affected by it the same way.
Sim800 supports SSL protocol. AT command "AT+CIPSSL" sets TCP to use SSL function.
In the "sim800_series_ssl_application_note_v1.01.pdf" is noted that: "Module will automatic begin SSL certificate after TCP connected."
My Problem: What is the exact meaning of the begin SSL certificate? what does sim800 do exactly? Does sim800 get SSL certificate from website? where does sim800 save SSL certificate?
As far as I know, SIM800 has some certificates in it and when you use a TCP+SSL or HTTP+SSL connection it will automatically use those certificates.
If those certificates are not ok for you, you will need to use an SD card, save there the certificates you want and use the command AT+SSLSETCERT to set the certificate you saved on your SD card. Here you can find how to use the File System.
Usually the certificates that come with the module are enough and you won't need this. But for example they didn't work for me when I tried to communicate with Azure via MQTT. I had to encrypt the data myself using wolfSSL library and send it using TCP without SSL.
Note: Not all SIM800 modules have SD card support.
There are a very few information about sim800 and ssl certificate on the web, and like you i got a lot of questions about it.
About your questions on how does sim800 get certificate and where does it save it, it seems, according to sim800_series_ssl_application_note_v1.01.pdf, that you can create (defining your own path), write and import a ssl certificate on your own with the AT+FSCREATE, AT+FSWRITE and AT+SSLSETCERT commands. An example is provided at the paragraph 3.10.
I'm sorry, i can't answer your other questions.
Anyway, if you get further informations about sim800 and ssl, i would be grateful if you share it with me.
When you use AT+CIPSSL you tell the SIM-module to use the SSL connection with TCP. When you use +CIPSTART command->
SIM module requests the TCP connection with the server through SSL.
Server sends the Server SSL certificate.
The authenticity of that certificate is checked with internal certificate authority certificate (The one that resides inside SIM-module) which is cryptographically connected with server certificate.
If the authenticity of certificate can not be confirmed SIM-module will close the connection unless you use the command AT+SSLOPT=0,0 (which forces the SIM-module to ignore invalid certificate authentication) prior to AT+CIPSSL command.
//Key exchange
SIM-module then encrypts it's master key (already inside SIM-module cannot be changed or read) with the public key (Which is part of the already sent server certificate) and sends it back to server.
Server then encrypts it's master key with SIM-module's master-key and sends it back to SIM-module. Key exchange is now complete as both (server and SIM-module) recieved master keys.
SIM-module currently doesn't support Client authentication which means that server cannot authenticate the client. That means there must be some other option of authentication (For example in MQTT that can be username and password that only client knows)
If you want your module to be able to authenticate server you will need to create the self-signed certificate for server and certificate authority certificate (for SIM-module) which is cryptographically connected to self-signed certificate and upload them to server and SIM-module (through AT+SSLSETCERT command from SD card).
If you only want to encrypt the data traffic you can ignore invalid certificate (AT+SSLOPT=0,0) as you will recieve publickey nevertheless. But if you want to be sure about server authenticity you will need to upload right certificate to module.
Hey everyone just a quick question.
Lets say I am connected to a server with a SSL connection. Now say while I am connected the Certificate expires. Will the connection close or is nothing going to happen at all?
I would think that nothing will happen at all but I'm not 100 % sure.
It depends on the client implementation.
However, the connection will likely remain active as the validity of the certificate is checked during the TLS/SSL handshake, which happens once at the beginning of the session when the connection is opened.
The certificate will be checked once for validity at the beginning of the connection, and again during the connection (or a subsequent one sharing the same session) if either side requests a full handshake, which is usually only done to escalate the cipher suites, request a client certificate, etc.
To extend the other answers: the certificate will only be checked within a full handshake. Usually at most one full handshake is done per TCP connection (at the beginning) but with renegotiation another full handshake might be done.
But with session resumption only the first TCP connection in the SSL session will do a full handshake. This means that it will not detect a changed or expired certificate even when establishing a new TCP connection as long as an existing SSL session is resumed inside this TCP connection.
The reasoning behind this: The certificate is used to make sure that the SSL session is with the expected party and not some man in the middle attacker. So it must be checked at the beginning of the SSL session, i.e. a whenever a full handshake is done. Since an established SSL session is integrity protected a man in the middle tampering with the connection would be detected. So one does not again need to verify the certificate during the SSL.
I have Local Webserver that configured to use SSL connection.
The question is - would there be any handshakes if i try to open https://localhost from any browser?
The "classic" SSL handshake would require public keys and certs exchange on the network level to create Derive keys. But if we are trying to connect to local webserver, there would be no packets required for SSL handshake (Already tested with Wireshark).
So, does handshake really happens, but on the upper OSI level? Or it doesnt happen at all, and there are no derive key creation?
Would there be any handshakes if i try to open https://localhost from any browser?
Yes,
The "classic" SSL handshake would require public keys and certs exchange on the network level to create Derive keys.
No. It requires a certificate, and a premaster secret, and mutual negotiation of a master key from which session keys are derived. All this is irrelevant.
But if we are trying to connect to local webserver, there would be no packets required for SSL handshake (Already tested with Wireshark).
Wireshark can't see loopback packets.
So, does handshake really happens
Yes.
but on the upper OSI level?
SSL happens in the application layer of the TCP model. The OSI model does not apply to TCP/IP. TCP/IP has its own model.
Or it doesn't happen at all
It does.
and there are no derive key creation?
There is creation of a pre-master secret, a master secret, and a session key. You seem to have some misconception of this process, but again it isn't relevant.
I am testing a web service with an external partner using 2 way SSL under IIS 7.5. I am requiring SSL, requiring a client cert, and using one to one mapping to authenticate to a domain account. I have configured everything and it works fine on our network (I am able to provide a client cert, get authenticated and invoke the service from browser and test harness).
From outside of our network (in most cases, see below), I am getting a 403.7 error. I have gone through the machine level certificate store and made sure the certificates and CAs are trusted.
Here's the weird thing. I obtained a Type I cert to test from home (and got 403.7 like our intended partner is). So I setup Fiddler to debug SSL and send my certificate, and this works for some reason. I setup a test harness to pass the exact same certificate, and got 403.7. I test in my browser (IE 9), don't get a prompt for a client cert, and get 403.7.
Any help appreciated.
Bill
Last time I checked, IIS was using re-negotiation (by default) to get the client certificate: there is a first handshake where the server doesn't request a client certificate, followed by another handshake (encrypted this time) where the server requests the certificate (via a TLS CertificateRequest message). This will prevent you from seeing anything from Wireshark, unless you configure it to use the server's private key and decipher the traffic (note that this only works with some cipher suites).
One way to see the client-certificate negotiation is to configure IIS to use initial client certificate negotiation, using netsh and clientcertnegotiation=true (which is about initial negotiation). At least the CertificateRequest and the certificate will be sent in clear during the handshake, so you should be able to see this with Wireshark.
If the client isn't sending a certificate to the server as a response to the CertificateRequest, you'll still see an empty Certificate message from the client.
If you don't export the private key with the certificate to use with Fiddler or whichever other client, there is no chance that it will be able to use the certificate. It may at best try to send the certificate, but the handshake will fail (since the CertificateVerify message needs to be signed by the client's private key).
I guess you may encounter a problem whereby:
not presenting a certificate is accepted by the server (it's effectively optional),
presenting an invalid certificate makes it fail and causes this 403.7 status code (many servers and SSL/TLS stacks would implement this as a fatal error, but TLS specification doesn't say that unsupported_certificate, certificate_revoked, certificate_expired, certificate_unknown should be fatal, so this is at the server's discretion).
Are you using the same physical machine to test both the in-network and external-network connections? If not, are you sure that the external-network client has the private key accessible?
I have not configured Fiddler client authentication before. Does it read the client certificate and key from the standard certificate stores? Does it read directly from a PKCS12?
One other thing that may be helpful is inspecting the TLS handshake in WireShark. Specifically, check out the Server's "Certificate Request" message, as the data here clues the client (IE9) which client certificates it should display in the prompt. Compare this for the internal and external connections.