Hot answers tagged stunnel
You can disable SSLv3 protocol on stunnel altogether. From stunnel documentation: sslVersion = SSL_VERSION select version of SSL protocol Allowed options: all, SSLv2, SSLv3, TLSv1, TLSv1.1, TLSv1.2 I've added this to the config file: sslVersion = TLSv1 TLSv1.1 TLSv1.2 And now I am not able to connect with SSLv3 (using openssl s_client -...
The CAFile option configures a CA to use for client authentication certificates; this isn't what you want. Instead, you want to craft the file in the cert option to contain the entire applicable certificate chain. You'll want to save a backup copy of that file, then make a new one; basically combining the two files, formatted like this: -----BEGIN ...
This is about HTTP keep-alive, which allows for multiple resource requests to come through a single TCP session (and, with SSL, a single SSL session). This is of great importance to the performance of an SSL site, as without keep-alive, an SSL handshake would be needed for each requested resource. So, the concern here is one big keep-alive session from the ...
You may have both stunnel3 & stunnel4 installed on your system. The default for "stunnel" is to softlink it to stunnel3: root@sibelius:/usr/bin# ls -l stunnel* lrwxrwxrwx 1 root root 8 Oct 18 2011 stunnel -> stunnel3 -rwxr-xr-x 1 root root 2797 Oct 18 2011 stunnel3 -rwxr-xr-x 1 root root 109904 Oct 18 2011 stunnel4 The syntax of the ...
if you prefer to stick with older stunnel (like the 4.53 in your Debian Stable), you can disable SSLv2 and SSLv3 with: sslVersion = all options = NO_SSLv2 options = NO_SSLv3 instead of sslVersion = TLSv1 which would disable TLSv1.1 and TLSv1.2 also.
Ok, problem was solved... I added this to configuration: sslVersion = all options = NO_SSLv2 As far as I understand, error was related to SSLv23. Now all works as expected.
OpenVPN over TLS Your VPN is using TCP as a transport protocol. The stunnel instance is used to encapsulate the content of the TCP stream in TLS/TCP. You get this protocol stack: [IP ]<------------------------>[IP ] [OpenVPN]<------------------------>[OpenVPN] [TLS ]<~~~~~>[TLS] [TCP ]<->[TCP ]<----->[TCP]<->[...
It doesn't; the application needs to be configured to point to the tunnel endpoint. In the case you're referring to, the client would need to be reconfigured to point to the local stunnel listener, which will wrap the connection data and send it to the server according to the stunnel configuration. There's also "transparent proxy" mode, which involves ...
STunnel 4.45 fixes this properly using some new capabilities (proxy protocol) coming with HAProxy 1.15 http://stunnel.mirt.net/pipermail/stunnel-announce/2011-October/000062.html http://haproxy.1wt.eu/download/1.5/doc/proxy-protocol.txt It also fixes the issues with previous patches and Keep Alive
4.1 Use strong cryptography and security protocols (for example, SSL/TLS, IPSEC, SSH, etc.) to safeguard sensitive cardholder data during transmission over open, public networks. Yes, your architecture is appropriate to the standard. https://www.pcisecuritystandards.org/documents/pci_dss_v2.pdf
So to clarify: You want passwords to be allowed from the office network, but not from anywhere else. You, however, need to be able to connect from anywhere. On my network SSH keys are required when logging in from outside but either keys or passwords can be used when connecting from another host on the inside. Here's how that works: /etc/ssh/sshd_config ...
This is an old question now, but HaProxy now has native support for SSL which makes it a lot easier to setup and use with SSL/TLS. see here http://blog.exceliance.fr/2012/09/10/how-to-get-ssl-with-haproxy-getting-rid-of-stunnel-stud-nginx-or-pound/
Found my problem... It's not really documented (at least on my Ubuntu system). If I run the command > stunnel4 config.conf Then everything works, and all output shows up in the debug log file (if configured in the config file).
With one IP address, you need to use the TLS SNI extension. There's an example config here: http://serverfault.com/a/440563/216353 Server-side SNI requires stunnel version 4.38 or newer compiled with OpenSSL 1.0.0 or newer. Also, client support: IE7+ Chrome 6+ Firefox 2+ Opera 8+ Safari 3+ iOS4+ Also note that Windows XP does not support the SNI ...
The safest way to do this is to create a user account specifically for the stunnel service, and then apply the permissions appropriately Start > Run > lusrmgr.msc Right-click users and choose New user... Enter in the user details, and generate a strong password for the account (you'll only need it for the new few minutes, so just keep it in notepad for the ...
I am not familiar with the specifics of 10.10, but I am going to assume that it is pretty close to Debian. One thing you could do, is basically setup to separate stunnel configurations. On that accepts SSL, and forwards it to a local port, and another that listens on that local port, and then makes SSL connections to the external host. These two can be ...
SSL3_GET_RECORD:wrong version number is the key. It seems that lynx on your CentOS systems isn't using SSLv3. It'll be easier to check the exact behavior with openssl s_client: Check what happens with just SSLv3: openssl s_client -connect server:443 -ssl3 And with just TLS: openssl s_client -connect server:443 -tls1
You need to use TLS SNI to be able to present two different certificates on the same listening port. Be aware that some clients, notably most browsers running under Windows XP, do not support SNI. See the sni option in the documentation. Split your certificates into different files (the same private key is used for both public certificates): [https] cert ...
Similar to what I posted in another thread, HAProxy does support native SSL on both sides since 1.5-dev12. So having X-Forwarded-For, HTTP keep-alive as well as a header telling the server that the connection was made over SSL is as simple as the following : listen front bind :80 bind :443 ssl crt /etc/haproxy/haproxy.pem mode http option ...
I think netcat is perfect for this situation. "Netcat is a featured networking utility which reads and writes data across network connections, using the TCP/IP protocol." http://netcat.sourceforge.net/ http://en.wikipedia.org/wiki/Netcat/
From what I recall, stunnel simply relies on the ulimit setting to find its limit in file descriptors. So you just have to do "ulimit -n 65536" and you'll get a client limit around 32000. Be careful though, as each SSL context can use a lot of memory. Also, if your stunnel works in thread mode, you won't necessarily want to reach thread numbers that high.
You should make a network capture and see why it was rejected. Also check the logs on both end points. Increase the debug level in the stunnel conf. You need to make a network trace to figure out which version of the SSL protocol the client is supporting. Then make sure the your server supports that version too. A client sends a ClientHello message ...
When stunnel is in front of it does it mean that this port is now tls/ssl only? Yes, that is correct. A successful TLS negotiation is required before it will pass traffic upstream.
Looks like I found an answer myself. Why doesn't this IPv6 listen directive also accept IPv4? states from the nginx doc that In Linux by default any IPv6 TCP socket also accepts IPv4 traffic ... the runtime parameter: net.ipv6.bindv6only which has the value 0 by default. So I used ONLY the [Server IPv6]. This gives only a tcp6 entry in netstat, but ...
ysdx's answer is great, and describes very well how the traffic will look on the wire. Left unmentioned, however, is that traffic analysis can go a long way toward identifying applications. Let's assume that your OpenVPN connection looks just like an https connection on the wire, so an attacker cannot read the byte stream and know what kind of ...
Is this 188.8.131.52 really your server's ip address, or are you NAT'd behind something? If you're NAT'd then your accept = needs to point to your LAN ip. What is the output of ifconfig? Or I wonder if the /etc/services/ file is preventing you from binding port 443 to a service other than https; If that's really the ip address, try commenting out ...
stunnel is a program to create a gateway between non-SSL and SSL. From the description on the home page: Stunnel is a proxy designed to add TLS encryption functionality to existing clients and servers without any changes in the programs' code This tool is not designed to create a gateway from SSL to SSL. What you need in your case is just a simple TCP ...
I suspect that you are running with more than one process and the stats you're seeing are the one of the process that catches your stats request. One more reason never to run more than one process at a time and to remove the "nbproc" line.
I've found the solution for this problem. I've been using SSL in server mode when I actually needed client mode.
The key is to allow non-existent interfaces to be bound to by programs (like stunnel, HA-proxy). So that when keepalived flips the virtual IP onto that box, the programs are already listening and waiting for traffic on that interface. This can be done by modifying your /etc/sysctl.conf by including the key/value pair of: net.ipv4.ip_nonlocal_bind=1 More ...
Only top voted, non community-wiki answers of a minimum length are eligible