Tag Info

Hot answers tagged

16

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 ...


14

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 ...


11

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 ...


8

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 ...


5

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 ...


5

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/


5

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


5

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


5

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.


4

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).


4

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 ...


4

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 ...


3

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.


3

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/


3

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 ...


3

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


3

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.


3

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.


3

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 ...


2

Set client = yes in the [myservice] section. This tells stunnel that the connect (aka "server") side is the SSL one and the accept (aka "client") side is plain. The default is the opposite, which requires an SSL certificate. But that's not all! For some insane reason, stunnel defaults to completely insecure mode that does no verification of the server's ...


2

Your goal with your actual tools can't be reached, because stunnel is unable to do this back-connecting feature, ssh won't work as a daemon, and has a little bit different protocol from https. Enough smart IDS-es will be able to detect that. What you had to do: As @NilsToedtmann suggested, you should use some type of tricky thing, at least an OpenVPN. ...


2

I would go with the ssh-tunnel and do it with autossh instead of ssh. About the performance I would say, that the SSH protocol is highly customizable and you could fine tune your connection, if needed. But I would not expect a noticeable overhead after the connection is set up.


2

As you have already stated in your update and the following output tells you: Error binding pop3s to 0.0.0.0:110 bind: Permission denied (13) You'll need elevated privileges to bind a service to a port. From the top of my head I believe non-root users can only bind services to ports above 1024 and 0-1024 is reserved for root. As far as your question for ...


2

You cannot bind to ports <= 1024 without root permissions, this is a security thing. If you set your ports > 1024, you should be fine.


2

Extending the excelent answer from Shane, you could use Nginx as SSL terminator in front of HAproxy. It correctly handles keep-alive between client and nginx which is the most latency sensitive side and makes a new connection to backend for each client request, sending the X-FORWARDED-FOR in each one.


2

I've found the solution for this problem. I've been using SSL in server mode when I actually needed client mode.


2

Nixnotwin, that's a genuine problem all right, but I'm completely confused about how you think what you're asking for will help you. Let me restate the problem so we can see if I've understood it correctly. You have an ssh server with lots of weak user passwords. You want to be able to log in remotely from offsite, but don't want to allow your foolish ...


2

You can turn off encryption in ssh by using the -c none option. I would do this then you can also turn it on later if needed without having to re-engineer your whole solution.


2

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 ...


2

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