I'm using Wireshark to analyse network traffic for a TLS request. I can filter the request based on the website IP address and I can see things like TCP session setup (3-way handshake), client hello, server hello, etc. Based on my understanding I should be receiving a "certificate" packet from the server after the 'Server Hello' where I can see the website certificate as well as any intermediate certificates... but unfortunately I'm not receiving a "certificate" packet...
I've tried this on Windows (Wireshark version Version 3.6.6) and Ubuntu 20.04 (Wireshark version 3.2.3) and it's the same for both.
Should I be receiving a certificate packet? If so, any clues as to why I'm not seeing it?
Related
I am new to HTTPs. In our application to integrate with another system we were given HTTPs URLs along with their certificates. Our team added those certificates in the test store. Now when we are sending request on those URLs, we are getting “Unsupported or unrecognized SSL message”.
And if I do curl -v on that URL, I get error:1408F10B:SSL routines:ssl3_get_record:wrong version number.
Is it problem on our side or this need to be fixed by other systems who shared those URLs with us.
Both of these errors are due to the same reason?
It is very likely that the server does not speak TLS at all.
The client will start with the TLS handshake and the server will reply to this with some non-TLS response. The client expect the server to do its part of the TLS handshake though. Thus it will try to interpret the servers as response as TLS. This will lead to strange error messages depending on the TLS stack used by the client.
With OpenSSL based stacks it will often result in wrong version number, since the trying to extract the TLS version number for the expected TLS record and get some unexpected results since the server did not actually send a TLS record.
Is it problem on our side or this need to be fixed by other systems who shared those URLs with us.
If this is exact the URL you are supposed to use (i.e. no simply changing of http:// to https:// on your site) then it is likely a server side problem. But it might also be a problem of some middlebox or software in the network path to the server, like some antivirus, firewall or captive portal hijacking your data and denying access to the remote system with an error message.
In my case, I had on apache2 another badly configured virtual host. On the other wrong virtual host there was a http virtual server on port 443!!!
The second virtual host was correct but apache cannot use different protocols on the same port for different virtual hosts.
After removing the http on port 443 configuration all other https hosts worked and error
error:1408F10B:SSL routines:ssl3_get_record:wrong version number"
disapeared
As I understand it Virtual Hosts work in HTTP servers by receiving a HTTP request from the client and examining the Host header, which contains service1.example.com or service2.example.com, etc. and then forwarding the request based on some rules in the HTTP server configuration.
But as I understand it TLS works as follows:
Client opens connection to server.
Client and server have a handshake where the client checks the server's certificate is valid for the name the client is trying to access.
Client transmits the request.
Server transmits the response.
These two seem like they would be incompatible, the server doesn't know which TLS certificate to present to the client until after the request has been sent, but the client won't send the request until the handshake is completed.
They clearly aren't incompatible, I have run web servers with multiple separate TLS virtual hosts each with completely separate certificates. Where have I gone wrong here?
I am in a big issue regarding TLSv1.2 and unable to resolve this.
Scenario:
Hostapd should act as an integrated EAP server.I have an openwrt device on which hostapdv2.6-devel is running.
2.Wpa_Supplicant is acting as a client and should talk to hostapd for successful authentication.wpa_supplicantv2.6-devel is running on a different openwrt device.
3.Two way SSL handshake(EAP-TLS) should happen successfully and hostapd should authenticate the client device without any issue.
4.Requirement is that this communication should take place on TLSv1.2 i.e. server (hostapd)is bound to send TLSv1.2.
Configuration:
EAP server(hostapd configuration):
1.Since by default server is sending TLSv1.0 to the client so I made it to send TLSv1.2 forcefully by recompiling the package for TLSv12 and install again on the router.
2.Created a configuration file, which has all the server certificate, ca certificate chain eap_server=1 etc.
3.Started the hostapd process on the device successfully.
client configuration(wpa_supplicant):
1.Created a configuration file, which has all client certificate, CA chain, identity, SSID etc.
2.Started the wpa_supplicant on the device successfully.
SSL transactions:
1.client send client hello message and TLSv1.2 in it.
2.Server responds with server hello message and TLSv1.2
3.Server sends its certificate, serverkeyexchange, certificate request message.
4.Afterward a fatal alert occurs "decode_error" and no more transaction are seen and authentication gets failed.
Please see the wireshark capture below.
ClientHello
ServerHello
Alert Message
Kindly help me to resolve this issue as its making my life difficult.
Please let me know if any other information is required.
Thanks.
I have been trying to configure a simple pass through proxy using wso2 esb, which points to a REST service in https port.
I had tried doing the same using my development machine (Windows 7) and it is successful.
But when I try repeating the same in production server, in RHEL, I get The system cannot infer the transport information error in system log.
Things Tried
Created passthrough proxy service pointing to https://some.domain.in/something/something.
Tried CURL to https://some.domain.in/something/something and its shows the response properly
Imported certificate from the site to client-truststore.jks. Same was done locally and it worked.
in axis2.xml, edited <parameter name="HostnameVerifier">AllowAll</parameter>under https transporter
Error Message
When clicked in test in configuration console, I got the following message, Invalid address
CURL the proxy service URL, and got Empty response
Checked system logs and saw below logs
Am I missing out something?
I could see in the wso2-error-logs following messages
ERROR {org.apache.synapse.transport.passthru.TargetHandler} - I/O
error: handshake alert: unrecognized_name
javax.net.ssl.SSLProtocolException: handshake alert: unrecognized_name
Then I realised that I was using java 1.6 locally but 1.7 in production.
And in Java 1.7 there are some changes in SSL handling
The JDK 7 release supports
the Server Name Indication (SNI) extension in the JSSE client. SNI,
described in RFC 4366 enables TLS clients to connect to virtual
servers.
In order to bypass this, I added JAVA_OPTS="-Djsse.enableSNIExtension=false" in wso2server.sh and restarted.
This solved my problem.
Not sure if this is the correct way though
This url helped me finally
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.