1 question about Stunnel. I would like to use Stunnel as a FIX (Financial Information eXchange) gateway for internet, to support both SSL and non-SSL connection. Is Stunnel able to do without any encryption? I just had a try with plain socket but it looked Stunnel rejected the connection saying 'invalid protocol' or something.
It's possible to use SSL/TLS without encryption using cipher suites with null encryption (e.g. TLS_RSA_WITH_NULL_SHA), which are normally disabled by default, but could be set via the ciphers option of Stunnel. However, you would still be using SSL/TLS, which isn't what you seem to be looking for.
It looks like you're more generally looking for what's usually called a TCP bouncer. You should be able to find a number of implementations around.
Related
I have a couple questions.
If I were to use TLS1.0->1.3 Client-Side and never use SSLv2 or v3, would there be any impacts on TCP Client Handshake Compatibility?
As in, would there ever be a server that wouldn't support this change that would require me to use SSLv2/v3?
I guess what i'm asking is if TLS is backwards compatible which servers that use SSLv2/v3 or do I not understand SSL/TLS properly?
Also other way around, if I was running an OS that had no support for TLS, would I at some point end up with Protocol Issues when Handshaking an SSL Stream?
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.
I am trying to connect a client to a secure (SSL/TLS) IMAP server. The client code cannot handle SSL/TLS correctly, so I am trying to see if a proxy server can be used in the middle. I was thinking something like the following:
IMAP Client <------- Plain Text Requests -------> Proxy <------- SSL/TLS Requests -------> SSL/TLS protected IMAP server.
I think this is possible but I am curious on what products can be used for the proxy? And, is this a normal deployment option?
Thanks much,
Ash
Use stunnel. With it you can do direct TLS (i.e. imaps, port 993) and also TLS upgrade of a plain IMAP connection (port 143) using the STARTTLS command. See the documentation for more details.
This is insane. An obvious fix is to find out why your client software cannot handle TLS. Deploying proxies or standalone tunnels makes little sense.
Seriously, if your "client" cannot even establish a TLS connection, it's either severely misconfigured, has damaged installation, or so bad that it won't reliably work even after you deploy this bandaid.
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).
All,
It is possible to use IIS (or similar) to handle the ssl side of https communications. Is there something similar that can handle the ssl side of a TCP/IP message?
Basically I have a client device sending a non-http message over a TCP connection and want a server that can handle the crypto and certificate side of SSL for me and forward the plain text on to another server.
The openSSL s_server command seems correct but the documentation states "It's intended for testing purposes only" while I need something robust. Is the documentation out of date?
Thanks,
Patrick
You are after the stunnel program:
Stunnel is a program that allows you to encrypt arbitrary TCP connections inside SSL (Secure Sockets Layer) available on both Unix and Windows. Stunnel can allow you to secure non-SSL aware daemons and protocols (like POP, IMAP, LDAP, etc) by having Stunnel provide the encryption, requiring no changes to the daemon's code.
I don't think the documentation is out of date. "For testing purposes only" is their release from liability.
It sounds like you want an SSL tunnel. You could setup a tunnel to the SSL server, send the packets through the tunnel, and then have that server forward the result on. There are lots of tutorials on using SSH to setup tunnels over SSL.