For my current project i need to implement http over tls at client ,for this i need a local server able to simulate this . is there any online or offline tool. which i can use and and see the handshake in wireshark .
For watching the TLS handshake you might not get far enough with wireshark. For such kind of monitoring you would ensure the security is low enough for wireshark to be able getting the session key from watching the handshake for decoding the later parts. Thus, you need to avoid any forward secrecy.
Otherwise any (https) server that is accessible (and willing to talk) to your client will do.
In case you are in an environment that is supported (e.g. any unix/linux), you might try using openssl. It allows setting up a server that will do handshake. And it will log the handshake such that you will be able looking at what is going on. This will eliminate the need for using wireshark for debugging.
For achieving this you need a Web Server accepting connection over TLS.I have achieved this on Apache Tomcat web Server.
TLS configuration needs to be done in the server.xml file present in config directory of Tomcat webserver. Connector tag needs to be added in the server.xml file that contains information like
TLS version to be used, port, List of supported Cipher Suites, Keystore path and password, Truststore path and password.
Any regular Rest client can be used to make a call like Postman client. But to use that over TLS/SSL certificate is needed to be installed in Chrome browser.
Hope this answers your doubt.
Related
I would like to seek for your advice if you have any idea or you have already encountered this issue “SSL/TLS handshake Issue” ?
To give you a summary, we’re getting an error the error below when connecting to Coupa (ERP) through HTTP.
Remote host closed connection. Possible SSL/TLS handshake issue. Check protocols, cipher suites and certificate set up. Use -Djavax.net.debug=ssl for further debugging.
We have several HTTP requests using the same HTTP config, but there’s this only one specific request that gives the said error. Also, this HTTP request works in postman. This occurs only in one Mule environment (UAT Environment). It works fine in our sandbox environment.
We are not sure whether the SSL connection/Handshake is closed on our end or server end.
If ever its on our end, how do we identify the fix for that?
If it’s on the server end, what should be the proof that we need to provide to them to say that the issue is on their end.
The server -Coupa in this case- is closing the connection just after it was opened by the client -a Mule application- probably before the client can send the HTTP request. The server could do this by any of a number of causes and the client does not receive any error messages or codes to indicate a reason. You will need to learn the reason from the server side.
Usual reasons are because an HTTPS connection doesn't match thee required ciphers suites or protocol versions accepted by the server, or because the client IP is not whitelisted. In those situations documentation from what's acceptable to the server side is useful. There could some other reasons that are known only to the server side.
A method to troubleshoot TLS connection issues is to do a traffic capture of the TCP packets, ideally from both sides, but if you don't control the server it will be only possible from the client. Another option if you are using HTTPS is to enable Java SSL Debug log in the Mule runtime to print the HTTPS connection information. You need to understand how to troubleshoot TLS to use these tools.
I'm working with Delphi and using Indy components for SSL connection. I had Fiddler2 running and was able to see SSL traffic, but had to upgrade Indy to newer version because it had some errors. For compatibility between Indy and OpenSSL I also upgraded to OpenSSL1.0.2a. After this upgrade it seems that it has switched to SSL3.3 a newer protocol than what was used before. I installed Fiddler4.5, .NET framework 4.5 and enabled TLS1.2 as descriped on http://blogs.telerik.com/fiddler/posts/13-02-11/fiddler-and-modern-tls-versions. I also reimported Fiddler's certificate to my trusted root certificates, however i can still not decrypt the SSL traffic.
Following is written in Fiddler:
This is a CONNECT tunnel, through which encrypted HTTPS traffic flows.
Fiddler's HTTPS Decryption feature is enabled, but this specific tunnel was configured not to be decrypted. Session Flag 'X-No-Decrypt' was set to: 'PeekYieldedUnknownProtocol'.
A SSLv3-compatible ServerHello handshake was found. Fiddler extracted the parameters below.
Version: 3.3 (TLS/1.2)
I tried to search Indy and OpenSSL source for the string "X-No-Decrypt", but it does not seem to be included anywhere. Accoring to fiddlers documentation it seems to be a string that you can include if you dont want fiddler to decrypt this particular session, but i have no idea where this string is included from.
Any suggestions?
Thanks /Rune
The text PeekYieldedUnknownProtocol indicates that when Fiddler looked at the first bytes sent by the client within the CONNECT tunnel, those bytes were not those of a HTTPS handshake. To avoid breaking whatever type of traffic is flowing through the tunnel, Fiddler simply passes the bytes back and forth without interpreting them.
To debug this further, your best bet would be to contact me using Help > Send Feedback in Fiddler. If you can send me a SAZ File (File > Save Session Archive) containing the traffic, I can investigate this problem further.
If you can't share a SAZ file, please at least right-click on the CONNECT in the Web Sessions list and choose Properties. Update your question with the value of the x-CONNECT-Peek flag.
Would like to write SSL Socket client server application on the same machine (both server and clients are running same machine). Should I use SSL certificate file (.pem file ) or not required.
Just I want encrypt the data before sending via socket.
Can we encrypt the data without .pem file?
Please advice me.
-Bala
SSL has two major steps:
check the identity of the peer, e.g. make sure you talk to the right one and not an imposter (e.g. man in the middle). This is done with certificates.
encrypt the connection, so that anybody listening on the wire cannot understand what's going on. Obviously encryption helps nothing if somebody is actively listening on the wire, because you failed in step#1. In this case you have no end-to-end encryption but an end-to-imposter and imposter-to-end encryption :)
Considering these arguments: do you still want to skip checking the certificate?
If you want it is doable, just look for anonymous authentication, e.g. ADH or aNULL with openssl.
Is this possible?
My understanding goes as far as this:
A non-proxy aware client will negotiate SSL directly with a listener, without every sending a CONNECT request to identify the destination host. A transparent proxy would need a destination host in order to forge a certificate with the hostname for the client.
I've read that some browser support the "server_name" extension in the client hello message which will identify the destination host and that if the extension is present this can be done. However, I'm unaware which browsers if any support this extension.
I would think that this should be possible but my efforts so far using squid and burp haven't been successful.
I understand that there's no way to obtain the destination host in the initial connection phase but I would think that with the correct configuration it would be possible to allow a forwarded connection in the initial phase then capture the returned certificate in order to read the destination then be able to inject the proxy's own CA-signed certificate at this point with the hostname derived from the legitimate certificate.
I think the best bet to get this working (if it's at all possible) is using squid's bump-server-first method http://wiki.squid-cache.org/Features/BumpSslServerFirst
I'm interested to hear if anyone has ever successfully gotten this to work.
I'm pretty far out of my depth here, so bear with me. We're using JDBC via com.intersys.jdbc.cachedriver to run stored procedures in Intersystems Cache and get the results in Java. However, there are other clients that connect directly to the Cache using a terminal over telnet. We have to lock down Cache's telnet port so that only telnet over SSL is possible. However, the Cache experts here say that locking down one port in Cache locks them all down, so the Java to Cache connection will also have to use SSL. I understand vaguely that some JDBC drivers support SSL, but I don't see that the Cache one does. What I need to know is:
What's needed to configure SSL for the JDBC connections? (We're using JBoss 4.2.3)
What about certificates? I assume those have to go somewhere.
Is it actually true that locking down the telnet connections is also going lock down JDBC in the same way?
Configuring Java Clients to Use SSL/TLS with Caché
Using SSL/TLS with Caché
Telnet vs ssh is a question about what the OS allows and only relates to Cache peripherally. It doesn't mean anything regarding items 1 or 2. So in answer to the direct question you are asking, "No".
1. What's needed to configure SSL for the JDBC connections? (We're using JBoss 4.2.3)
See http://docs.intersystems.com/cache20102/csp/docbook/DocBook.UI.Page.cls?KEY=GCAS_ssltls#GCAS_ssltls_javacli for details. This section doesn't explicitly mention JDBC, but it's true for JDBC (and the reference has been added for the documentation 2011.1 [next release] .)
2. What about certificates? I assume those have to go somewhere.
To quote the documentation: "If the client has a private key and certificate, these are stored in the client’s keystore; the keystore can also hold the client’s root CA certificate and any intermediate CA certificates. To authenticate the server, the client may need to have the root CA certificate for the server and any intermediate CA certificates, these can be stored either in the client’s truststore or along with client certificate information in the keystore. For more information on keystores and truststores, see the section “Keystores and Truststores” in the Java Secure Socket Extension (JSSE) Reference Guide."
3. Is it actually true that locking down the telnet connections is also going lock down JDBC in the same way?
Yes -- if telnet connections are to require TLS, then the superserver TLS setting needs to be Required, which means that you have to use TLS for anything that goes through the superserver (including JDBC). If you just want to allow the use of TLS for telnet connections, set the TLS value to Enabled, which allows non-TLS connections by other means (such as JDBC).