From the at loude.st  Tue Sep  3 08:56:04 2013
From: the at loude.st (Ronald Ning)
Date: Mon, 2 Sep 2013 23:56:04 -0700
Subject: [stunnel-users] stunnel 4.56 to 4.50 on andriod
Message-ID: <CADeAzJiYd4gkiTLdhhAYzB4-0gpdFJrEvy-_9C1gwEvm4qy-UA@mail.gmail.com>

Anyone have any luck running stunnel on android?  I'm running the stock JB
4.2.2.  I've tried every stunnel version from 4.50 to 4.56.   When I try to
run:

root at andriod: /system/bin/stunnel stunnel.conf
-> stunnel

root at andriod: netstat -a

netstat doesn't show the listening port:

My stunnel.conf is this:

client = yes
debug =  7

[ssh]
accept=2222
connect=myserver.com:22
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.stunnel.org/pipermail/stunnel-users/attachments/20130902/87bd7919/attachment.html>

From mohsin.mirza at mbc.net  Tue Sep  3 09:05:07 2013
From: mohsin.mirza at mbc.net (Mohsin Mirza)
Date: Tue, 3 Sep 2013 11:05:07 +0400
Subject: [stunnel-users] stunnel 4.56 to 4.50 on andriod
In-Reply-To: <CADeAzJiYd4gkiTLdhhAYzB4-0gpdFJrEvy-_9C1gwEvm4qy-UA@mail.gmail.com>
References: <CADeAzJiYd4gkiTLdhhAYzB4-0gpdFJrEvy-_9C1gwEvm4qy-UA@mail.gmail.com>
Message-ID: <52258A23.7060907@mbc.net>

Hi Ronald,

I facing same issue on JB 4.3 and 4.3.1

Please let me know if you any answers.


On 09/03/2013 10:56 AM, Ronald Ning wrote:
> Anyone have any luck running stunnel on android?  I'm running the 
> stock JB 4.2.2.  I've tried every stunnel version from 4.50 to 4.56.   
> When I try to run:
>
> root at andriod: /system/bin/stunnel stunnel.conf
> -> stunnel
>
> root at andriod: netstat -a
>
> netstat doesn't show the listening port:
>
> My stunnel.conf is this:
>
>     client = yes
>     debug =  7
>
>     [ssh]
>     accept=2222
>     connect=myserver.com:22 <http://myserver.com:22>
>
>
>
>
> _______________________________________________
> stunnel-users mailing list
> stunnel-users at stunnel.org
> https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users


________________________________________Disclaimer:
This email and any attachments may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately by email and destroy this email. Any unauthorized copying, dissemination, disclosure or distribution of the material in this email is strictly forbidden.
Unless expressly stated to the contrary, the sender of this email is not authorized by MBC to make any representations, negotiations or enter into any agreement on behalf of MBC. This e-mail message and any attached files have been scanned for the presence of computer viruses. However, it is the responsibility of the recipient to ensure that it is virus free; we accept no responsibility for any loss or damage arising in any way from its use.________________________________________

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.stunnel.org/pipermail/stunnel-users/attachments/20130903/e5880980/attachment.html>

From ralf29587 at gmx.de  Tue Sep  3 13:14:25 2013
From: ralf29587 at gmx.de (ralf29587 at gmx.de)
Date: Tue, 03 Sep 2013 13:14:25 +0200
Subject: [stunnel-users] IRC-Reconnect failed with "[10053] Software caused
 connection abort"(mIRC) and "SSL_connect: Peer suddenly
 disconnected"(tstunnel.exe)
Message-ID: <5225C491.3040009@gmx.de>

Hi,

I have a problem using stunnel with mIRC:

I was using a pretty old version of stunnel.exe that was packed with a 
mIRC script and could be ran as a command-line-only application without 
a configuration file (supplying all necessary informations parameters).
I know that current mIRC version have their own ssl support, but I 
prefer an old version without because it has much better performance.
The old one was used by "stunnel.exe -c -d localhost:<localport> -r 
<irc-server-ip>:<irc-server-port>" in command line and "/server 
localhost:<localport>" in irc.

A few of my servers stopped supporting an old ssl version, this old 
stunnel.exe is no longer compatible to the new (open)ssl dll files and 
so I had to upgrade to the most recent version of stunnel - and I have 
some problems make it run properly.

Here you can see my configuration file (stunnel.conf):

    ; Sample stunnel configuration file for Win32 by Michal Trojnara
    2002-2012
    ; Some options used here may be inadequate for your particular
    configuration
    ; This sample file does *not* represent stunnel.conf defaults
    ; Please consult the manual for detailed description of available
    options

    ;
    **************************************************************************
    ; * Global
    options                                                         *
    ;
    **************************************************************************

    ; Debugging stuff (may useful for troubleshooting)
    ;debug = 7
    ;output = stunnel.log

    ; Disable FIPS mode to allow non-approved protocols and algorithms
    ;fips = no

    ;
    **************************************************************************
    ; * Service defaults may also be specified in individual service
    sections  *
    ;
    **************************************************************************

    ; Certificate/key is needed in server mode and optional in client mode
    ;cert = stunnel.pem
    ;key = stunnel.pem

    ; Authentication stuff needs to be configured to prevent MITM attacks
    ; It is not enabled by default!
    ;verify = 2
    ; Don't forget to c_rehash CApath
    ;CApath = certs
    ; It's often easier to use CAfile
    ;CAfile = certs.pem
    ; Don't forget to c_rehash CRLpath
    ;CRLpath = crls
    ; Alternatively CRLfile can be used
    ;CRLfile = crls.pem

    ; Disable support for insecure SSLv2 protocol
    options = NO_SSLv2
    ; Workaround for Eudora bug
    ;options = DONT_INSERT_EMPTY_FRAGMENTS

    ; These options provide additional security at some performance
    degradation
    ;options = SINGLE_ECDH_USE
    ;options = SINGLE_DH_USE

    ;
    **************************************************************************
    ; * Service definitions (at least one service has to be
    defined)           *
    ;
    **************************************************************************

    ; Example SSL server mode services

    ;[pop3s]
    ;accept  = 995
    ;connect = 110

    ;[imaps]
    ;accept  = 993
    ;connect = 143

    ;[ssmtp]
    ;accept  = 465
    ;connect = 25

    ; Example SSL client mode services

    ;[gmail-pop3]
    ;client = yes
    ;accept = 127.0.0.1:110
    ;connect = pop.gmail.com:995

    ;[gmail-imap]
    ;client = yes
    ;accept = 127.0.0.1:143
    ;connect = imap.gmail.com:993

    ;[gmail-smtp]
    ;client = yes
    ;accept = 127.0.0.1:25
    ;connect = smtp.gmail.com:465

    ; Example SSL front-end to a web server

    ;[https]
    ;accept  = 443
    ;connect = 80
    ; "TIMEOUTclose = 0" is a workaround for a design flaw in Microsoft SSL
    ; Microsoft implementations do not use SSL close-notify alert and thus
    ; they are vulnerable to truncation attacks
    ;TIMEOUTclose = 0

    ; vim:ft=dosini

    [abjects]
    client = yes
    accept = 127.0.0.1:7001
    connect = irc.abjects.net:9999

    [Elite-IRC]
    client = yes
    accept = 127.0.0.1:7002
    connect = SpeedSpace-IRC.eu:6697

    [BodenTruppe]
    client = yes
    accept = 127.0.0.1:7003
    connect = boden-truppe.zapto.org:7001

    [LinkNet]
    client = yes
    accept = 127.0.0.1:7004
    connect = irc.link-net.nl:7000


The first connect always works properly (as shown in the log below):

    2013.09.03 12:30:45 LOG5[10696:9140]: stunnel 4.56 on
    x86-pc-msvc-1500 platform
    2013.09.03 12:30:45 LOG5[10696:9140]: Compiled/running with OpenSSL
    1.0.1e-fips11 Feb 2013
    2013.09.03 12:30:45 LOG5[10696:9140]: Threading:WIN32
    Sockets:SELECT,IPv6 SSL:ENGINE,OCSP,FIPS
    2013.09.03 12:30:45 LOG5[10696:9140]: Reading configuration from
    file stunnel.conf
    2013.09.03 12:30:45 LOG5[10696:9140]: FIPS mode is enabled
    2013.09.03 12:30:45 LOG5[10696:9140]: Configuration successful
    2013.09.03 12:30:53 LOG5[10696:10756]: Service [abjects] accepted
    connection from 127.0.0.1:3397
    2013.09.03 12:30:53 LOG5[10696:10756]: connect_blocking: connected
    188.126.73.62:9999
    2013.09.03 12:30:53 LOG5[10696:10756]: Service [abjects] connected
    remote server from 192.168.1.10:3398
    2013.09.03 12:30:54 LOG5[10696:14396]: Service [LinkNet] accepted
    connection from 127.0.0.1:3399
    2013.09.03 12:30:54 LOG5[10696:14396]: connect_blocking: connected
    194.126.217.98:7000
    2013.09.03 12:30:54 LOG5[10696:14396]: Service [LinkNet] connected
    remote server from 192.168.1.10:3400
    2013.09.03 12:30:54 LOG5[10696:2916]: Service [BodenTruppe] accepted
    connectionfrom 127.0.0.1:3401
    2013.09.03 12:30:54 LOG5[10696:2916]: connect_blocking: connected
    178.254.22.94:7001
    2013.09.03 12:30:54 LOG5[10696:2916]: Service [BodenTruppe]
    connected remote server from 192.168.1.10:3402
    2013.09.03 12:30:54 LOG5[10696:12260]: Service [Elite-IRC] accepted
    connection from 127.0.0.1:3403
    2013.09.03 12:30:54 LOG5[10696:12260]: connect_blocking: connected
    62.75.235.122:6697
    2013.09.03 12:30:54 LOG5[10696:12260]: Service [Elite-IRC] connected
    remote server from 192.168.1.10:3404


But when I try to reconnect, it doesn't work for 2 of my 4 servers
This is an example for what happens to Elite-IRC:

    2013.09.03 12:32:22 LOG5[10696:12260]: Connection closed: 1972
    byte(s) sent to SSL, 26903 byte(s) sent to socket
    2013.09.03 12:32:23 LOG5[10696:17168]: Service [Elite-IRC] accepted
    connection from 127.0.0.1:3429
    2013.09.03 12:32:23 LOG5[10696:17168]: connect_blocking: connected
    62.75.235.122:6697
    2013.09.03 12:32:23 LOG5[10696:17168]: Service [Elite-IRC] connected
    remote server from 192.168.1.10:3430
    2013.09.03 12:32:23 LOG3[10696:17168]: SSL_connect: Peer suddenly
    disconnected
    2013.09.03 12:32:23 LOG5[10696:17168]: Connection reset: 0 byte(s)
    sent to SSL,0 byte(s) sent to socket

The frist line shows the manual disconnect occured by executing "/server 
localhost:7002" in mIRC.
The second line shows the new incoming connection from my mIRC.
The third line? ... I got no clue why it has to block anything.
The fourth line: Successfully connected to IRC-Server?
And then the fifth line occurs. I'm not sure if I interpret it right, 
but for some reason tstunnel.exe is kicking out my connected mIRC client 
which makes mIRC to tell me "[10053] Software caused connection abort".

The whole lines in mIRC are:

    [12:34pm] * Connect retry #1 localhost (7003)
    ------------------------------------------------------------
    [12:34pm] * [10053] Software caused connection abort
    ------------------------------------------------------------
    [12:34pm] * Disconnected

By the way, I have packed libeay32.dll, ssleay32.dll, stunnel.conf and 
tstunnel.exe in a subdir in mIRC directory
and I'm starting it using "tstunnel.exe stunnel.conf"

When this error occurs, I have to kill tstunnel.exe and start it again - 
then everything works fine again.
For 1 of 4 servers, I also had this error with the old command-line 
stunnel.exe and I just wrote a script killing (only this) stunnel.exe 
and restarting it when this mIRC error occurs. Unfortunately this is no 
longer possible when tstunnel.exe is using a configuration file and one 
process is managing all connections.


Is there any way I can fix this?
(Maybe by fixing the logout of my local mIRC from my local tstunnel.exe?)

Best regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.stunnel.org/pipermail/stunnel-users/attachments/20130903/9cab4670/attachment.html>

From Michal.Trojnara at mirt.net  Tue Sep  3 18:52:40 2013
From: Michal.Trojnara at mirt.net (Michal Trojnara)
Date: Tue, 03 Sep 2013 18:52:40 +0200
Subject: [stunnel-users] IRC-Reconnect failed with "[10053] Software
 caused connection abort"(mIRC) and "SSL_connect: Peer suddenly
 disconnected"(tstunnel.exe)
In-Reply-To: <5225C491.3040009@gmx.de>
References: <5225C491.3040009@gmx.de>
Message-ID: <522613D8.4080701@mirt.net>

On 2013-09-03 13:14, ralf29587 wrote:
> When this error occurs, I have to kill tstunnel.exe and start it again
> - then everything works fine again.

This is a very interesting bug.  It took me a while to diagnose it.  It
looks like when stunnel connects to the same server the second time and
offers to resume the previously negotiated session (to avoid using
time-consuming asymmetric cryptography), the remote server just
disconnects the TCP session.  This is probably not the most graceful way
to handle an unsupported feature.  I wonder what software do they use
for SSL...

The workaround is to prevent stunnel from sending session tickets with
the following configuration file option:
    options = NO_TICKET
You can either specify the option globally, or only in the specific
sections of the malfunctioning servers.

Mike

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: OpenPGP digital signature
URL: <http://www.stunnel.org/pipermail/stunnel-users/attachments/20130903/8ed522f6/attachment.sig>

From kxkvi at wi.rr.com  Wed Sep  4 03:33:30 2013
From: kxkvi at wi.rr.com (Thomas Eifert)
Date: Tue, 03 Sep 2013 20:33:30 -0500
Subject: [stunnel-users] Stunnel North American FTP Down?
Message-ID: <52268DEA.8050406@wi.rr.com>

This evening, I'm unable to access the North American Stunnel FTP site.

If I go in with Filezilla in passive mode, I can do a directory listing, 
but the directory
is empty.

If I use the browser by clicking on the FTP link on the stunnel web 
page, I get an
error 550 Failed to change directory.

I was able to access the European site, however.

Enjoy the day.

-- 
Attention: This message and all attachments are private and may contain information that is confidential and privileged. If you received this message in error, please notify the sender by reply email and delete the message immediately.



From krzysiek at leeds.pl  Thu Sep  5 17:50:06 2013
From: krzysiek at leeds.pl (Krzysztof Kwiatkowski)
Date: Thu, 05 Sep 2013 17:50:06 +0200
Subject: [stunnel-users] Fullduplex in stunnel
Message-ID: <95a21c3f4d4a675c2fd66be4f1bceaf8@flogreenserver.dyndns.org>

Hi,

I'm planning to use stunnel to do stress testing of my application. I 
decided to use stunnel because I've noticed that full-duplex has been 
added to version 3.2 (around 1999) and my application handles high 
throughput.
AFAIK Stunnel uses openssl. Also I know that openssl doesn't handle 
fullduplex traffic very well. In fact without any tricks, half-duplex is 
most what I could get from openssl.
As the full-duplex feature has been added to stunnel in 1999 (so long 
time ago) can you confirm that it is still there and full-duplex is 
still supported? If it is a case, how it is possible that stunnel 
handles fullduplex?

Krzysztof Kwiatkowski


From Michal.Trojnara at mirt.net  Sat Sep  7 23:42:04 2013
From: Michal.Trojnara at mirt.net (Michal Trojnara)
Date: Sat, 07 Sep 2013 23:42:04 +0200
Subject: [stunnel-users] Fullduplex in stunnel
In-Reply-To: <95a21c3f4d4a675c2fd66be4f1bceaf8@flogreenserver.dyndns.org>
References: <95a21c3f4d4a675c2fd66be4f1bceaf8@flogreenserver.dyndns.org>
Message-ID: <522B9DAC.70405@mirt.net>

On 2013-09-05 17:50, Krzysztof Kwiatkowski wrote:
> I'm planning to use stunnel to do stress testing of my application. I
> decided to use stunnel because I've noticed that full-duplex has been
> added to version 3.2 (around 1999) and my application handles high
> throughput.
> AFAIK Stunnel uses openssl. Also I know that openssl doesn't handle
> fullduplex traffic very well. In fact without any tricks, half-duplex
> is most what I could get from openssl.
> As the full-duplex feature has been added to stunnel in 1999 (so long
> time ago) can you confirm that it is still there and full-duplex is
> still supported? If it is a case, how it is possible that stunnel
> handles fullduplex?

Well... It depends on how you define "tricks".  Doing full duplex data
transfer was definitely nontrivial.  Handling of half-closed connections
was was even harder.  My solution boils down to a state machine
implemented with asynchronous handling of read/write/close events using
non-blocking sockets.  All the details you need are within the
transfer() function in the src/client.c file.

Mike

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: OpenPGP digital signature
URL: <http://www.stunnel.org/pipermail/stunnel-users/attachments/20130907/78205cc9/attachment.sig>

From scottgsikorski at yahoo.com  Tue Sep 10 04:39:15 2013
From: scottgsikorski at yahoo.com (Scott Sikorski)
Date: Mon, 09 Sep 2013 21:39:15 -0500
Subject: [stunnel-users] stunnel accept a t3 connection?
Message-ID: <522E8653.8070009@yahoo.com>

I am curious if stunnel can support listening for an incoming t3 connection?

I am having difficulty getting t3s to work between WebSphere and 
WebLogic for API calls and am curious if an alternative such as stunnel 
will work.

I have stunnel installed betwen a client and the destination host, but 
the client doesn't seem to want to accept a t3://127.0.0.1:14010 
connection but when I change this to http://127.0.0.1:14010 it works fine.

Anything you can share would be appreciated.  Mostly, if it will never 
work, that would be nice to know as to not spend more time troubleshooting.

Best Regards,

Scott Sikorski
scottgsikorski at yahoo.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.stunnel.org/pipermail/stunnel-users/attachments/20130909/2c8ffa3d/attachment.html>

From Michal.Trojnara at mirt.net  Tue Sep 10 09:44:25 2013
From: Michal.Trojnara at mirt.net (Michal Trojnara)
Date: Tue, 10 Sep 2013 09:44:25 +0200
Subject: [stunnel-users] stunnel accept a t3 connection?
In-Reply-To: <522E8653.8070009@yahoo.com>
References: <522E8653.8070009@yahoo.com>
Message-ID: <522ECDD9.7040105@mirt.net>

On 09/10/2013 04:39 AM, Scott Sikorski wrote:
> I am curious if stunnel can support listening for an incoming t3 
> connection?
>
> I am having difficulty getting t3s to work between WebSphere and 
> WebLogic for API calls and am curious if an alternative such as 
> stunnel will work.
>
> I have stunnel installed betwen a client and the destination host, but 
> the client doesn't seem to want to accept a t3://127.0.0.1:14010 
> connection but when I change this to http://127.0.0.1:14010 it works 
> fine.
>
> Anything you can share would be appreciated.  Mostly, if it will never 
> work, that would be nice to know as to not spend more time 
> troubleshooting.

As far as I understand the documentation:
http://docs.oracle.com/cd/E13222_01/wls/docs45/classdocs/API_secure.html
t3s is just t3 over ssl.  It should work.  Please let us know the 
outcome of your tests.

Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.stunnel.org/pipermail/stunnel-users/attachments/20130910/fc28c12a/attachment.html>

From fslama at comcast.net  Thu Sep 12 18:20:05 2013
From: fslama at comcast.net (fslama at comcast.net)
Date: Thu, 12 Sep 2013 16:20:05 +0000 (UTC)
Subject: [stunnel-users] Hostname verification, support for, and patches
In-Reply-To: <874630292.2658729.1379000826789.JavaMail.root@comcast.net>
Message-ID: <1350163619.2676997.1379002805271.JavaMail.root@comcast.net>

After scouring the net I've found several isolated discussions regarding stunnel hostname validation. 
And also some patches that seem to implement hostname validation: 

https://www.stunnel.org/pipermail/stunnel-users/2010-March/002613.html 

I have a requirement to have stunnel (4.56) validate client certificates and their identity by comparing the its CNAME against the source address. 

I recall reading one response (which I can't find at the moment) from Marzena Trojnara indicating that this feature won't be supported. 
If so, can you explain the rational? 

Are there sanctioned patches out there today? 


Regards, 
-Fred 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.stunnel.org/pipermail/stunnel-users/attachments/20130912/e17705a2/attachment.html>

From ralf29587 at gmx.de  Fri Sep 13 12:27:19 2013
From: ralf29587 at gmx.de (ralf29587 at gmx.de)
Date: Fri, 13 Sep 2013 12:27:19 +0200
Subject: [stunnel-users] IRC-Reconnect failed with "[10053] Software
 caused connection abort"(mIRC) and "SSL_connect: Peer suddenly
 disconnected"(tstunnel.exe)
In-Reply-To: <5226A04C.4010209@gmx.de>
References: <5225C491.3040009@gmx.de> <522613D8.4080701@mirt.net>
 <5226A04C.4010209@gmx.de>
Message-ID: <5232E887.7040105@gmx.de>

Could some admin please remove my uploaded VCard and either my Name or 
my E-Mail-Adress shown on stunnel.org ??

Thanks a million!


From Nikolaus at rath.org  Sat Sep 14 07:55:14 2013
From: Nikolaus at rath.org (Nikolaus Rath)
Date: Fri, 13 Sep 2013 22:55:14 -0700
Subject: [stunnel-users] Difference between verify=2, 3 and 4
Message-ID: <5233FA42.7050400@rath.org>

Hello,

Thanks for writing stunnel, it looks like a great tool!

I have, however, a really hard time understanding the difference between
verify=2,3 and 4. In the manpage, I found

       verify = level
           verify peer certificate

           level 0 - request and ignore peer certificate
           level 1 - verify peer certificate if present
           level 2 - verify peer certificate
           level 3 - verify peer with locally installed certificate
           level 4 - ignore CA chain and only verify peer certificate
           default - no verify

Levels 0-2 seem pretty clear cut, but then it becomes confusing for me.

First, I do not understand how level 3 differs from level2. What does
"against a locally installed certificate" mean? It seems to me that I
certainly need to have a local copy of the trusted CAs even in level 2
-- at least I hope that they aren't somehow build in to stunnel. But
there is also just one CApath option, so will that be used for level 2
or level 3?

For level 4, the "ignore the CA chain" path is fine -- but where do I
put the peer certificates that I'm willing to accept? CApath seems
wrong, but cert is already used for the server's own certificate...


Best,

   -Nikolaus

-- 
 »Time flies like an arrow, fruit flies like a Banana.«

  PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C



From cwestin at yahoo.com  Mon Sep 16 17:19:16 2013
From: cwestin at yahoo.com (Chris Westin)
Date: Mon, 16 Sep 2013 08:19:16 -0700 (PDT)
Subject: [stunnel-users] Looking for a tech talk speaker on Secure Networking
Message-ID: <1379344756.39183.YahooMailNeo@web142802.mail.bf1.yahoo.com>

I organize the speakers for the SF Bay Area Large-Scale Production Engineering
meetup (http://www.meetup.com/SF-Bay-Area-Large-Scale-Production-Engineering/ ;
take a look at the "PAST" tab to see the kinds of events we've had).

For our event on Thursday October 17, 2013, I'm looking for speakers on the
topic of "Secure Networking" (event: http://www.meetup.com/SF-Bay-Area-Large-Scale-Production-Engineering/events/129859602/ ).

As you can see from looking at our past events, I pick a topic, and
then try to get 2-3 talks on that topic. Talks are usually 20-25 minutes
long. This is a technical audience, and they don't appreciate a marketing
pitch. They're eager to get into the nuts and bolts of the topic, including
demos, code samples, and architecture.

If you're going to be in the Bay Area then, and would be interested in giving
a talk, please let me know here, or (preferably) through meetup.com.

Thanks,
Chris Westin



From meresponde2001-stn at yahoo.es  Tue Sep 17 01:17:16 2013
From: meresponde2001-stn at yahoo.es (Javier)
Date: Tue, 17 Sep 2013 01:17:16 +0200
Subject: [stunnel-users] Difference between verify=2, 3 and 4
In-Reply-To: <5233FA42.7050400@rath.org>
References: <5233FA42.7050400@rath.org>
Message-ID: <20130917011716.d9a1f3b36f7dd1d853d5ec60@yahoo.es>

On Fri, 13 Sep 2013 22:55:14 -0700
Nikolaus Rath <Nikolaus at rath.org> wrote:

> Hello,
> 
> Thanks for writing stunnel, it looks like a great tool!
> 
> I have, however, a really hard time understanding the difference between
> verify=2,3 and 4. In the manpage, I found
> 
>        verify = level
>            verify peer certificate
> 
>            level 0 - request and ignore peer certificate
>            level 1 - verify peer certificate if present
>            level 2 - verify peer certificate
>            level 3 - verify peer with locally installed certificate
>            level 4 - ignore CA chain and only verify peer certificate
>            default - no verify
> 
> Levels 0-2 seem pretty clear cut, but then it becomes confusing for me.
> 
> First, I do not understand how level 3 differs from level2. What does
> "against a locally installed certificate" mean? It seems to me that I
> certainly need to have a local copy of the trusted CAs even in level 2
> -- at least I hope that they aren't somehow build in to stunnel. But
> there is also just one CApath option, so will that be used for level 2
> or level 3?

Hi,

They differ in how you manage certificates to validate them.

The level 2 verify the peer certificate against CA (CAfile).

The level 3 verify the peer certificate against CA and also with a local copy
of that certificate in the CAfile. In other words, in addition to the CAs 
certificates you'll have the incoming peer certificates in that file. And you 
verify that not only is valid against the CA, but against the certificate itself,
in that file.

It's a way of a double check to ensure it's not a fake certificate.

> For level 4, the "ignore the CA chain" path is fine -- but where do I
> put the peer certificates that I'm willing to accept? CApath seems
> wrong, but cert is already used for the server's own certificate...

In the CAfile.

I didn't use level 4, but if I'm not wrong, it doesn't check for a local certificate
but just the top CA, without the full CAs chain (all CAs part of the certificate).

If no one corrects me, L4 is as I told. But the best way is to test it.

Regards.


From Michal.Trojnara at mirt.net  Thu Sep 19 21:05:44 2013
From: Michal.Trojnara at mirt.net (Michal Trojnara)
Date: Thu, 19 Sep 2013 21:05:44 +0200
Subject: [stunnel-users] Difference between verify=2, 3 and 4
In-Reply-To: <20130917011716.d9a1f3b36f7dd1d853d5ec60@yahoo.es>
References: <5233FA42.7050400@rath.org>
 <20130917011716.d9a1f3b36f7dd1d853d5ec60@yahoo.es>
Message-ID: <523B4B08.70204@mirt.net>

On 2013-09-17 01:17, Javier wrote:
> I didn't use level 4, but if I'm not wrong, it doesn't check for a local certificate
> but just the top CA, without the full CAs chain (all CAs part of the certificate).
>
> If no one corrects me, L4 is as I told. But the best way is to test it.

It looks like I'll be the one to correct you.  It is the opposite:
"verify = 4" *only* checks your peer certificate, ignoring all the other
certs in the chain.  The rationale behind this mode is to be able to use:
1. Specific certificates issued by CAs you don't trust for any other
certificates.  This can also be achieved by "verify = 3".
2. Specific certificates issued by CAs for which you don't *have* the
root certificate.  This may happen, as SSL does only requires servers to
send the remaining part of the chain.  Sending the root certificate
itself is optional.

IMHO most stunnel deployments *should* use "verify = 4".

Mike

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: OpenPGP digital signature
URL: <http://www.stunnel.org/pipermail/stunnel-users/attachments/20130919/758edeae/attachment.sig>

From Michal.Trojnara at mirt.net  Thu Sep 19 22:04:15 2013
From: Michal.Trojnara at mirt.net (Michal Trojnara)
Date: Thu, 19 Sep 2013 22:04:15 +0200
Subject: [stunnel-users] Hostname verification, support for, and patches
In-Reply-To: <1350163619.2676997.1379002805271.JavaMail.root@comcast.net>
References: <1350163619.2676997.1379002805271.JavaMail.root@comcast.net>
Message-ID: <523B58BF.9080506@mirt.net>

On 2013-09-12 18:20, fslama at comcast.net wrote:
> I have a requirement to have stunnel (4.56) validate client
> certificates and their identity by comparing the its CNAME against the
> source address.
Can you elaborate on this?  What to you mean by source address? 
IPv4/IPv4 IP address?  FQDN retrieved with reverse DNS lookup?

> I recall reading one response (which I can't find at the moment)
> from Marzena Trojnara indicating that this feature won't be supported.
> If so, can you explain the rational?
The rationale is as follows:
1. FQDN verification was introduced to check whether the web site the
browser connected to is indeed the web site intended by the browser.
2. For server mode (to verify peer clients) it would not be possible to
check *intended* peer address, as it is client that initiates the
connection and not server, thus a server has no way to know what the
*intended* peer is.  Comparing CNAME/SubjectAltName against client's IP
address or FQDN would be pointless from security perspective, as both
are spoofable.
3. For client mode (to verify peer servers) it is much better (i.e. more
secure) to just download peer certificate and use "verify = 4".  Web
browsers have to rely on CNAME/SubjectAltName checks, as unlike stunnel
they don't know in advance the identity of servers they'll connect to.
4. Proper FQDN validation is a complex task.  There were many security
vulnerabilities in mainstream browsers due to the complexity of IDN and
wildcard certificates.

I also recommend reading chapter 3 (Endpoint Identification) of RFC 2818
(http://tools.ietf.org/html/rfc2818).  This document is specific to
HTTPS, as HTTPS is currently the only SSL based protocol that relies on
CNAME/SubjectAltName for authentication.

Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.stunnel.org/pipermail/stunnel-users/attachments/20130919/f3b83d61/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: OpenPGP digital signature
URL: <http://www.stunnel.org/pipermail/stunnel-users/attachments/20130919/f3b83d61/attachment.sig>

From meresponde2001-stn at yahoo.es  Fri Sep 20 04:30:32 2013
From: meresponde2001-stn at yahoo.es (Javier)
Date: Fri, 20 Sep 2013 04:30:32 +0200
Subject: [stunnel-users] Difference between verify=2, 3 and 4
In-Reply-To: <523B4B08.70204@mirt.net>
References: <5233FA42.7050400@rath.org>
 <20130917011716.d9a1f3b36f7dd1d853d5ec60@yahoo.es>
 <523B4B08.70204@mirt.net>
Message-ID: <20130920043032.24d83fbcac19d98978ab53ba@yahoo.es>

On Thu, 19 Sep 2013 21:05:44 +0200
Michal Trojnara <Michal.Trojnara at mirt.net> wrote:

> On 2013-09-17 01:17, Javier wrote:
> > I didn't use level 4, but if I'm not wrong, it doesn't check for a local certificate
> > but just the top CA, without the full CAs chain (all CAs part of the certificate).
> >
> > If no one corrects me, L4 is as I told. But the best way is to test it.
> 
> It looks like I'll be the one to correct you.

Hi.

Better you, as the developer, than anyone else haha. So, glad you did :)

>  It is the opposite:
> "verify = 4" *only* checks your peer certificate, ignoring all the other
> certs in the chain.  The rationale behind this mode is to be able to use:
> 1. Specific certificates issued by CAs you don't trust for any other
> certificates.  This can also be achieved by "verify = 3".
> 2. Specific certificates issued by CAs for which you don't *have* the
> root certificate.  This may happen, as SSL does only requires servers to
> send the remaining part of the chain.  Sending the root certificate
> itself is optional.
> 
> IMHO most stunnel deployments *should* use "verify = 4".

I think I understand now.

But a bit contradictory to accept a certificate that has been issued by a CA
you don't trust, just for the main purpose of establish an SSL connection.

It depends in the service you are offering, I guess.

I the other hand, I mainly use Stunnel in client mode.

Thanks for the explanation, Michal :)



From Nikolaus at rath.org  Fri Sep 20 05:27:17 2013
From: Nikolaus at rath.org (Nikolaus Rath)
Date: Thu, 19 Sep 2013 20:27:17 -0700
Subject: [stunnel-users] Difference between verify=2, 3 and 4
In-Reply-To: <523B4B08.70204@mirt.net> (Michal Trojnara's message of "Thu, 19
 Sep 2013 21:05:44 +0200")
References: <5233FA42.7050400@rath.org>
 <20130917011716.d9a1f3b36f7dd1d853d5ec60@yahoo.es>
 <523B4B08.70204@mirt.net>
Message-ID: <87eh8k5g16.fsf@vostro.rath.org>

Michal Trojnara <Michal.Trojnara at mirt.net> writes:
> On 2013-09-17 01:17, Javier wrote:
>> I didn't use level 4, but if I'm not wrong, it doesn't check for a local certificate
>> but just the top CA, without the full CAs chain (all CAs part of the certificate).
>>
>> If no one corrects me, L4 is as I told. But the best way is to test it.
>
> It looks like I'll be the one to correct you.  It is the opposite:
> "verify = 4" *only* checks your peer certificate, ignoring all the other
> certs in the chain.  The rationale behind this mode is to be able to use:
> 1. Specific certificates issued by CAs you don't trust for any other
> certificates.  This can also be achieved by "verify = 3".
> 2. Specific certificates issued by CAs for which you don't *have* the
> root certificate.  This may happen, as SSL does only requires servers to
> send the remaining part of the chain.  Sending the root certificate
> itself is optional.
>
> IMHO most stunnel deployments *should* use "verify = 4".

Thanks for explanations. So in which case would I ever use 3? Somehow I
can't think of such a situation. If I already explicitly trust a
specific certificate, why would I be interested in checking the CA
chain?


Best,

   -Nikolaus

-- 
 »Time flies like an arrow, fruit flies like a Banana.«

  PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C


From Michal.Trojnara at mirt.net  Fri Sep 20 07:28:37 2013
From: Michal.Trojnara at mirt.net (Michal Trojnara)
Date: Fri, 20 Sep 2013 07:28:37 +0200
Subject: [stunnel-users] Difference between verify=2, 3 and 4
In-Reply-To: <87eh8k5g16.fsf@vostro.rath.org>
References: <5233FA42.7050400@rath.org>
 <20130917011716.d9a1f3b36f7dd1d853d5ec60@yahoo.es> <523B4B08.70204@mirt.net>
 <87eh8k5g16.fsf@vostro.rath.org>
Message-ID: <523BDD05.2010706@mirt.net>

On 2013-09-20 05:27, Nikolaus Rath wrote:
>> IMHO most stunnel deployments *should* use "verify = 4".
> Thanks for explanations. So in which case would I ever use 3? Somehow I
> can't think of such a situation. If I already explicitly trust a
> specific certificate, why would I be interested in checking the CA
> chain?

Good point.  The reason is historical: "verify = 4" was added just 2
years ago.  As stunnel is 15 years old I decided to keep "verify = 3"
for backward compatibility.  Alternatively I could have replaced the
existing functionality of "verify = 3", but most people expect
modifications of the already defined functionality on software updates
to be as small as possible.

Mike

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: OpenPGP digital signature
URL: <http://www.stunnel.org/pipermail/stunnel-users/attachments/20130920/ac1c27ef/attachment.sig>

From Michal.Trojnara at mirt.net  Fri Sep 20 07:36:23 2013
From: Michal.Trojnara at mirt.net (Michal Trojnara)
Date: Fri, 20 Sep 2013 07:36:23 +0200
Subject: [stunnel-users] Difference between verify=2, 3 and 4
In-Reply-To: <20130920043032.24d83fbcac19d98978ab53ba@yahoo.es>
References: <5233FA42.7050400@rath.org>
 <20130917011716.d9a1f3b36f7dd1d853d5ec60@yahoo.es> <523B4B08.70204@mirt.net>
 <20130920043032.24d83fbcac19d98978ab53ba@yahoo.es>
Message-ID: <523BDED7.60404@mirt.net>

On 2013-09-20 04:30, Javier wrote:
> But a bit contradictory to accept a certificate that has been issued by a CA
> you don't trust, just for the main purpose of establish an SSL connection.

It seems to be contradictory, but it is not.  You often cannot control
the certificate of your peer server.  In case its certificate is issued
by a large CA, you really want to make sure you're connecting to this
specific server, and not any other server with certificate issued by the
same CA.  Web browsers use CNAME/SubjectAltName verification to solve
the same problem in a different way.

Mike

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: OpenPGP digital signature
URL: <http://www.stunnel.org/pipermail/stunnel-users/attachments/20130920/81cec2b5/attachment.sig>

From kxkvi at wi.rr.com  Fri Sep 20 10:10:27 2013
From: kxkvi at wi.rr.com (Thomas Eifert)
Date: Fri, 20 Sep 2013 03:10:27 -0500
Subject: [stunnel-users] Difference between verify=2, 3 and 4
In-Reply-To: <20130917011716.d9a1f3b36f7dd1d853d5ec60@yahoo.es>
References: <5233FA42.7050400@rath.org>
 <20130917011716.d9a1f3b36f7dd1d853d5ec60@yahoo.es>
Message-ID: <523C02F3.4030809@wi.rr.com>


On 9/16/2013 6:17 PM, Javier wrote:
> I didn't use level 4, but if I'm not wrong, it doesn't check for a 
> local certificate but just the top CA, without the full CAs chain (all 
> CAs part of the certificate). If no one corrects me, L4 is as I told. 
> But the best way is to test it.

Testing is the best way, for sure.  In theory, L4 checks for the peer 
certificate only.  Yet, I'm currently
using at least one peer certificate that requires the top CA to be 
present in the .pem file.  If I remove it,
L4 fails.  Go figure.

Best regards,

Thomas

-- 
Attention: This message and all attachments are private and may contain information that is confidential and privileged. If you received this message in error, please notify the sender by reply email and delete the message immediately.



From Michal.Trojnara at mirt.net  Fri Sep 20 12:16:46 2013
From: Michal.Trojnara at mirt.net (Michal Trojnara)
Date: Fri, 20 Sep 2013 12:16:46 +0200
Subject: [stunnel-users] Difference between verify=2, 3 and 4
In-Reply-To: <523C02F3.4030809@wi.rr.com>
References: <5233FA42.7050400@rath.org>
 <20130917011716.d9a1f3b36f7dd1d853d5ec60@yahoo.es>
 <523C02F3.4030809@wi.rr.com>
Message-ID: <523C208E.7020407@mirt.net>

On 09/20/2013 10:10 AM, Thomas Eifert wrote:
> Testing is the best way, for sure.  In theory, L4 checks for the peer 
> certificate only.  Yet, I'm currently
> using at least one peer certificate that requires the top CA to be 
> present in the .pem file.  If I remove it,
> L4 fails.  Go figure.

I wasn't able to reproduce this issue.  Could you send some more details.
A step-by-step procedure to would be great.

Mike


From Jochen.Bern at LINworks.de  Fri Sep 20 12:34:32 2013
From: Jochen.Bern at LINworks.de (Jochen Bern)
Date: Fri, 20 Sep 2013 12:34:32 +0200
Subject: [stunnel-users] Difference between verify=2, 3 and 4
In-Reply-To: <20130920043032.24d83fbcac19d98978ab53ba@yahoo.es>
References: <5233FA42.7050400@rath.org>
 <20130917011716.d9a1f3b36f7dd1d853d5ec60@yahoo.es> <523B4B08.70204@mirt.net>
 <20130920043032.24d83fbcac19d98978ab53ba@yahoo.es>
Message-ID: <523C24B8.8010105@LINworks.de>

On 20.09.2013 04:30, Javier wrote:
> But a bit contradictory to accept a certificate that has been issued by a CA
> you don't trust, just for the main purpose of establish an SSL connection.

Why? I can easily see a provider (say, e-mail) buying a server cert from
an ultra-el-cheapo CA that *I* wouldn't trust to hold the door open for
me. As long as that CA only gets the CSR from the provider (and never
sees the private key), there's no reason why I shouldn't trust *the
keypair*, though. And the server cert effectively is the embodiment of
that keypair / the pubkey in the SSL exchange.

(And "I don't care about the CA, just gimme encryption to prevent
eavesdropping" *is* how web browsers used HTTPS for quite some time.
Which then got supplanted by "everyone works along the list of CAs that
come preinstalled in browsers today" ... :-S )

On 20.09.2013 05:27, Nikolaus Rath wrote:
> So in which case would I ever use 3? Somehow I
> can't think of such a situation. If I already explicitly trust a
> specific certificate, why would I be interested in checking the CA
> chain?

Imagine the CA (or one of the intermediate CAs) getting compromised and
corresponding revocations becoming available to your machine (by OS
updates, OCSP, whatever) before you hear of the incident.

Regards,
								J. Bern
-- 
*NEU* - NEC IT-Infrastruktur-Produkte im <http://www.linworks-shop.de/>:
Server--Storage--Virtualisierung--Management SW--Passion for Performance
Jochen Bern, Systemingenieur --- LINworks GmbH <http://www.LINworks.de/>
Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt
PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27
Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202
Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel


From Nikolaus at rath.org  Fri Sep 20 18:25:24 2013
From: Nikolaus at rath.org (Nikolaus Rath)
Date: Fri, 20 Sep 2013 09:25:24 -0700
Subject: [stunnel-users] Difference between verify=2, 3 and 4
In-Reply-To: <523C24B8.8010105@LINworks.de> (Jochen Bern's message of "Fri, 20
 Sep 2013 12:34:32 +0200")
References: <5233FA42.7050400@rath.org>
 <20130917011716.d9a1f3b36f7dd1d853d5ec60@yahoo.es>
 <523B4B08.70204@mirt.net>
 <20130920043032.24d83fbcac19d98978ab53ba@yahoo.es>
 <523C24B8.8010105@LINworks.de>
Message-ID: <874n9f8npn.fsf@rath.org>

Jochen Bern <Jochen.Bern at LINworks.de> writes:
> On 20.09.2013 05:27, Nikolaus Rath wrote:
>> So in which case would I ever use 3? Somehow I
>> can't think of such a situation. If I already explicitly trust a
>> specific certificate, why would I be interested in checking the CA
>> chain?
>
> Imagine the CA (or one of the intermediate CAs) getting compromised and
> corresponding revocations becoming available to your machine (by OS
> updates, OCSP, whatever) before you hear of the incident.

FWIW, I still don't see why I'd use verify=3 in that case. 

Best,
Nikolaus

-- 
Encrypted emails preferred.
PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C

             »Time flies like an arrow, fruit flies like a Banana.«


From kxkvi at wi.rr.com  Fri Sep 20 18:38:43 2013
From: kxkvi at wi.rr.com (Thomas Eifert)
Date: Fri, 20 Sep 2013 11:38:43 -0500
Subject: [stunnel-users] Difference between verify=2, 3 and 4
In-Reply-To: <523C208E.7020407@mirt.net>
References: <5233FA42.7050400@rath.org>
 <20130917011716.d9a1f3b36f7dd1d853d5ec60@yahoo.es>
 <523C02F3.4030809@wi.rr.com> <523C208E.7020407@mirt.net>
Message-ID: <523C7A13.5070405@wi.rr.com>

Mike,

Okay, here's the simple way to test it.  This is repeatable in Stunnel 
4.56 and 5.00:

Start with a simple stunnel.conf:

debug = 6
fips = no
delay = yes
output = stunnel.log

[nntps.3]
client = yes
accept = 127.0.0.1:119
connect = news.eternal-september.org:563

Point your favorite newsreader to 127.0.0.1/119, then connect to the 
server.

Having done that, open the stunnel log window.  From the menu bar, 
choose "save peer certificate".

Save the certificate, which will now be "peer-nntps.3.pem" in the 
stunnel directory.

Add certificate verification to stunnel conf:

[nntps.3]
client = yes
cafile = peer-nntps.3.pem
verify = 4
accept = 127.0.0.1:119
connect = news.eternal-september.org:563

Reload the configuration file.

Attempt to reconnect to the server.  The certificate verify will fail:

2013.09.20 11:12:35 LOG4[3964]: CERT: Verification error: unable to get 
local issuer certificate
2013.09.20 11:12:35 LOG4[3964]: Certificate check failed: depth=0, 
/description=z8x2a0S5FjpJGCa7/C=DE/CN=news.eternal-september.org/emailAddress=wolfgang at weyand-hg.de
2013.09.20 11:12:35 LOG3[3964]: SSL_connect: 14090086: 
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate 
verify failed

If you paste the certificate for the root CA into the peer-nntps.3.pem 
file, then it will verify okay.

I have a feeling you'll find something wrong with the certificate that's 
causing this to happen.  The guy that runs the server
likes to "roll his own".

Best regards,

Thomas


On 9/20/2013 5:16 AM, Michal Trojnara wrote:
> On 09/20/2013 10:10 AM, Thomas Eifert wrote:
>> Testing is the best way, for sure.  In theory, L4 checks for the peer 
>> certificate only.  Yet, I'm currently
>> using at least one peer certificate that requires the top CA to be 
>> present in the .pem file.  If I remove it,
>> L4 fails.  Go figure.
>
> I wasn't able to reproduce this issue.  Could you send some more details.
> A step-by-step procedure to would be great.
>
> Mike
> _______________________________________________
> stunnel-users mailing list
> stunnel-users at stunnel.org
> https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users
>

-- 
Attention: This message and all attachments are private and may contain information that is confidential and privileged. If you received this message in error, please notify the sender by reply email and delete the message immediately.



From lholzheid at bihl-wiedemann.de  Fri Sep 20 19:29:38 2013
From: lholzheid at bihl-wiedemann.de (Ludolf Holzheid)
Date: Fri, 20 Sep 2013 19:29:38 +0200
Subject: [stunnel-users] Difference between verify=2, 3 and 4
In-Reply-To: <874n9f8npn.fsf@rath.org>
References: <5233FA42.7050400@rath.org>
 <20130917011716.d9a1f3b36f7dd1d853d5ec60@yahoo.es> <523B4B08.70204@mirt.net>
 <20130920043032.24d83fbcac19d98978ab53ba@yahoo.es>
 <523C24B8.8010105@LINworks.de> <874n9f8npn.fsf@rath.org>
Message-ID: <20130920172938.GC11536@shadow.bihl-wiedemann.de>

On Fri, 2013-09-20 09:25:24 -0700, Nikolaus Rath wrote:
> Jochen Bern <Jochen.Bern at LINworks.de> writes:
> > On 20.09.2013 05:27, Nikolaus Rath wrote:
> >> So in which case would I ever use 3? Somehow I
> >> can't think of such a situation. If I already explicitly trust a
> >> specific certificate, why would I be interested in checking the CA
> >> chain?
> >
> > Imagine the CA (or one of the intermediate CAs) getting compromised and
> > corresponding revocations becoming available to your machine (by OS
> > updates, OCSP, whatever) before you hear of the incident.
> 
> FWIW, I still don't see why I'd use verify=3 in that case. 

Nikolaus,

With verify=3, you don't explicitly trust the peer certificate, but
you restrict the use of /valid/ certificates issued by a certain CA to
the ones locally installed.

Revoking the server certificate or one of the intermediate
certificates renders the peer certificate as invalid and stunnel will
reject it (if the CRLs are available to stunnel), even though it still
is locally installed.

Ludolf

-- 

Bihl+Wiedemann GmbH
Floßwörthstraße 41
68199 Mannheim, Germany
 
Tel: +49 621 33996-0
Fax: +49 621 3392239
 
mailto:lholzheid at bihl-wiedemann.de
http://www.bihl-wiedemann.de
 
Sitz der Gesellschaft: Mannheim
Geschäftsführer: Jochen Bihl, Bernhard Wiedemann
Amtsgericht Mannheim, HRB 5796


From Jochen.Bern at LINworks.de  Fri Sep 20 20:33:16 2013
From: Jochen.Bern at LINworks.de (Jochen Bern)
Date: Fri, 20 Sep 2013 20:33:16 +0200
Subject: [stunnel-users] Difference between verify=2, 3 and 4
In-Reply-To: <874n9f8npn.fsf@rath.org>
References: <5233FA42.7050400@rath.org>
 <20130917011716.d9a1f3b36f7dd1d853d5ec60@yahoo.es> <523B4B08.70204@mirt.net>
 <20130920043032.24d83fbcac19d98978ab53ba@yahoo.es>
 <523C24B8.8010105@LINworks.de> <874n9f8npn.fsf@rath.org>
Message-ID: <523C94EC.5010300@LINworks.de>

On 20.09.2013 18:25, Nikolaus Rath wrote:
> Jochen Bern <Jochen.Bern at LINworks.de> writes:
>> On 20.09.2013 05:27, Nikolaus Rath wrote:
>>> So in which case would I ever use 3? Somehow I
>>> can't think of such a situation. If I already explicitly trust a
>>> specific certificate, why would I be interested in checking the CA
>>> chain?
>>
>> Imagine the CA (or one of the intermediate CAs) getting compromised and
>> corresponding revocations becoming available to your machine (by OS
>> updates, OCSP, whatever) before you hear of the incident.
> 
> FWIW, I still don't see why I'd use verify=3 in that case. 

Because verify=4 doesn't know the CA chain (barring the oddity reported
by Thomas) and thus would not consider the server cert invalid because
of the CA cert revocation.

Whether you *want* that to happen is a somewhat different question.
Under normal circumstances, one would expect such a situation to result
in the server operators installing a new server cert from another CA, at
which point your stunnel setup will stop working, anyway. (Unless the
attacker was able to snarf the server's privkey from the CA's archives
and has already set up a MitM attack against *your* connections.) In
other words, using 4 instead of 3 where possible gains you maybe a
couple days of continued operation, at the expense of probably not
learning that fast *how* the CA was compromised and what that means for
the trustworthiness of the server cert.

(I currently have another case at hand where the difference would be
much more pronounced, though. IMHO the CA blundered there - as in, the
server cert is valid until late 2015, but one intermediate CA's cert
expires early in 2014. Ho hum ... !)

Regards,
								J. Bern
-- 
*NEU* - NEC IT-Infrastruktur-Produkte im <http://www.linworks-shop.de/>:
Server--Storage--Virtualisierung--Management SW--Passion for Performance
Jochen Bern, Systemingenieur --- LINworks GmbH <http://www.LINworks.de/>
Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt
PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27
Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202
Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel


From robert7390 at comcast.net  Sat Sep 21 21:09:02 2013
From: robert7390 at comcast.net (Robert Bernier)
Date: Sat, 21 Sep 2013 12:09:02 -0700
Subject: [stunnel-users] postgres protocol
Message-ID: <3043065.9BJovo5XKU@wolf>

Hi,

I've been looking at using stunnel connecting it directly to postgres. As per the man page, https://www.stunnel.org/static/stunnel.html, I was able to get postgres version 8.3 working. However, I've not suceeded using postgres version 9.2.

Any insights would be appreciated.

Thanks

-- 
Robert Bernier

   PostgreSQL Business Intelligence Analyst
 
   robert7390 at comcast.net
   http://www.linkedin.com/pub/robert-bernier/69/6a6/921
   http://beknown.com/robert-bernier


From bxstover at yahoo.co.uk  Tue Sep 24 13:09:58 2013
From: bxstover at yahoo.co.uk (Ben Stover)
Date: Tue, 24 Sep 2013 13:09:58 +0200
Subject: [stunnel-users] One "client=yes" instruction per .conf file
	sufficient?
Message-ID: <735263.14877.bm@smtp130.mail.ir2.yahoo.com>

Is one 

client=yes

instruction line per conf file enough?

Does is mean all instructions in current .conf file belong to a client configuration 
or does it mean only the following command (=lines below) are intended for client usage?

Ben







From bxstover at yahoo.co.uk  Tue Sep 24 13:32:05 2013
From: bxstover at yahoo.co.uk (Ben Stover)
Date: Tue, 24 Sep 2013 13:32:05 +0200
Subject: [stunnel-users] Port assignment in .conf file for local email
	client unique?
Message-ID: <903885.98473.bm@smtp138.mail.ir2.yahoo.com>

Assume I want to connect from my local email client to two (!) remote email servers

The corresponding instructions in .conf file looks like (my guess):

[smtps-firstacct]
accept = 127.0.0.1:259
connect = smtps.myisp1.com:465

[smtps-secondacct]
accept = 127.0.0.1:259
connect = smtps.myisp2.com:465

Questions:

1.) a configuration like above with the same "accept" port 259  is NOT possible because
stunnel does not know to which remote email server he has to connect.
To distinguish  two different remote email server I always have to select TWO different accept-ports like

[smtps-firstacct]
accept = 127.0.0.1:259
connect = smtps.myisp1.com:465

[smtps-secondacct]
accept = 127.0.0.1:258
connect = smtps.myisp2.com:465

Correct?

2.) Can I use arbitrary accept-ports like 1242 or 23199 or is there a port range from I have to select one?

3.) Moreover assume I want to make the SSL connection transparent can I select an accept-port 25?

4.) I read somewhere that I have always to specify in email client for POP3/SMTP an address

127.0.0.1:9999

and NOT

127.0.0.1:259

in order to connect to local stunnel service. Because local stunnel service is always listening on port 9999.

Is this correct? 

Thank you
Ben











From gchodos at gmail.com  Tue Sep 24 14:43:27 2013
From: gchodos at gmail.com (Gary Chodos)
Date: Tue, 24 Sep 2013 08:43:27 -0400
Subject: [stunnel-users] Proxy HTTPS via stunnel without any certificates on
	proxy/stunnel box
Message-ID: <CANDYHM5_BnKDd8Xe3GZfzqBUN4zZk8+uZuho_XuH8Cm1DTtsdg@mail.gmail.com>

Greetings,

We are trying to decide between SNIProxy and stunnel for the following task:

- Client browser hits https://foo.bar.org, which resolves to an IP that
corresponds to the stunnel machine listening on 443.

- stunnel "forwards" (sorry if this is not the correct technical term) the
connection to a different machine, specified by a different IP address,
which is also configured to believe it is foo.bar.org and actually has a
web server listening on 443 and houses the SSL key/cert.

- when stunnel hits the end server, the latter sees the stunnel IP address
as source, not the original user's (who initiated the web request for
https://foo.bar.org).  I believe this is default behavior, but just noting
it for completeness.

Is it possible to accomplish this (stunnel listening on and connecting to
https endpoints) without housing any certs/keys on the stunnel machine
itself, because we want the second server to deal with all that and we do
not have access to those keys anyway.  And of course, the users which go to
the https://foo.bar.org should not see any cert mismatches as a result of
loading https://foo.bar.org which, for the user, will resolve to the
stunnel/proxy IP, rather than the end server which actually had a running
web server and keys/cert.

Sorry if the above detail is insufficient; do let me know.

Thanks for your help.

Gary
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.stunnel.org/pipermail/stunnel-users/attachments/20130924/a55ae3c6/attachment.html>

From fslama at comcast.net  Tue Sep 24 16:29:54 2013
From: fslama at comcast.net (Frederick Slama)
Date: Tue, 24 Sep 2013 10:29:54 -0400
Subject: [stunnel-users] Hostname verification, support for, and patches
In-Reply-To: <523B58BF.9080506@mirt.net>
References: <1350163619.2676997.1379002805271.JavaMail.root@comcast.net>
 <523B58BF.9080506@mirt.net>
Message-ID: <5A04F6AD-DC8C-4968-A346-D0BBC005C0D8@comcast.net>

Hi Mike,

Our application is not browser/HTTP based. We are running a daemon which does not have native SSL support. The clients have been modified to "speak" SSL (using java SSLSocket).
Our application runs within a secure network, however we want to encrypt the sensitive content of the protocol. Server-side host verification of the client seemed like a good way to authenticate the client.
Stunnel runs in server mode. We were contemplating the possibility of comparing the client's source address (from reverse DNS lookup) with the CNAME in the certificate.

It looks like your comment (#2) explains the problem with this approach.
	"Comparing CNAME/SubjectAltName against client's IP address or FQDN would be pointless from security perspective, as both are spoofable."

This statement is predicated on the DNS being tampered with, correct?
In our scenario it is unlikely that DNS would be tampered with -- of course, nothing is 100% guaranteed.

Thoughts?

I'll take a look at the link you suggested.


Regards,
-Fred

PS> As a disclaimer I am coming up to speed on SSL/TLS, so please excuse me if my questions/assumptions are 101 in nature.
PPS> Kudos on a well implemented tool.



On Sep 19, 2013, at 4:04 PM, Michal Trojnara <Michal.Trojnara at mirt.net> wrote:

> On 2013-09-12 18:20, fslama at comcast.net wrote:
>> I have a requirement to have stunnel (4.56) validate client certificates and their identity by comparing the its CNAME against the source address.
> Can you elaborate on this?  What to you mean by source address?  IPv4/IPv4 IP address?  FQDN retrieved with reverse DNS lookup?
> 
>> I recall reading one response (which I can't find at the moment) from Marzena Trojnara indicating that this feature won't be supported.
>> If so, can you explain the rational?
> The rationale is as follows:
> 1. FQDN verification was introduced to check whether the web site the browser connected to is indeed the web site intended by the browser.
> 2. For server mode (to verify peer clients) it would not be possible to check *intended* peer address, as it is client that initiates the connection and not server, thus a server has no way to know what the *intended* peer is.  Comparing CNAME/SubjectAltName against client's IP address or FQDN would be pointless from security perspective, as both are spoofable.
> 3. For client mode (to verify peer servers) it is much better (i.e. more secure) to just download peer certificate and use "verify = 4".  Web browsers have to rely on CNAME/SubjectAltName checks, as unlike stunnel they don't know in advance the identity of servers they'll connect to.
> 4. Proper FQDN validation is a complex task.  There were many security vulnerabilities in mainstream browsers due to the complexity of IDN and wildcard certificates.
> 
> I also recommend reading chapter 3 (Endpoint Identification) of RFC 2818 (http://tools.ietf.org/html/rfc2818).  This document is specific to HTTPS, as HTTPS is currently the only SSL based protocol that relies on CNAME/SubjectAltName for authentication.
> 
> Mike
> _______________________________________________
> stunnel-users mailing list
> stunnel-users at stunnel.org
> https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.stunnel.org/pipermail/stunnel-users/attachments/20130924/7cc9b5c7/attachment.html>

From Jason_Haar at trimble.com  Wed Sep 25 04:31:19 2013
From: Jason_Haar at trimble.com (Jason Haar)
Date: Wed, 25 Sep 2013 14:31:19 +1200
Subject: [stunnel-users] Proxy HTTPS via stunnel without any
 certificates on proxy/stunnel box
In-Reply-To: <CANDYHM5_BnKDd8Xe3GZfzqBUN4zZk8+uZuho_XuH8Cm1DTtsdg@mail.gmail.com>
References: <CANDYHM5_BnKDd8Xe3GZfzqBUN4zZk8+uZuho_XuH8Cm1DTtsdg@mail.gmail.com>
Message-ID: <52424AF7.1070206@trimble.com>

On 25/09/13 00:43, Gary Chodos wrote:
> We are trying to decide between SNIProxy and stunnel for the following
> task:
>
> - Client browser hits https://foo.bar.org, which resolves to an IP
> that corresponds to the stunnel machine listening on 443.
>
> - stunnel "forwards" (sorry if this is not the correct technical term)
> the connection to a different machine, specified by a different IP
> address, which is also configured to believe it is foo.bar.org
> <http://foo.bar.org> and actually has a web server listening on 443
> and houses the SSL key/cert.
>
What an odd setup. You want to make an HTTPS connection to an IP
address, but want that to make an HTTPS connection to another IP
address, but don't want it to house the SSL cert.

That isn't possible - an "SSL terminator" requires the cert - otherwise
it isn't terminating the SSL connection. Why don't you just use a
standard TCP forwarder instead - won't that do what you want? Don't
forget: SSL occurs *within* a TCP session - so a standard TCP forwarder
can "reroute" the SSL transaction without needing to know what it is
forwarding (ie no need for certs)

You could use xinetd or netcat - tonnes of options


-- 
Cheers

Jason Haar
Information Security Manager, Trimble Navigation Ltd.
Phone: +1 408 481 8171
PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.stunnel.org/pipermail/stunnel-users/attachments/20130925/78d60598/attachment.html>

From kxkvi at wi.rr.com  Wed Sep 25 05:45:47 2013
From: kxkvi at wi.rr.com (Thomas Eifert)
Date: Tue, 24 Sep 2013 22:45:47 -0500
Subject: [stunnel-users] Port assignment in .conf file for local email
 client unique?
In-Reply-To: <903885.98473.bm@smtp138.mail.ir2.yahoo.com>
References: <903885.98473.bm@smtp138.mail.ir2.yahoo.com>
Message-ID: <52425C6B.2050808@wi.rr.com>

Ben,

See replies below.

On 9/24/2013 6:32 AM, Ben Stover wrote:

> Assume I want to connect from my local email client to two (!) remote email servers
>
> The corresponding instructions in .conf file looks like (my guess):
>
> [smtps-firstacct]
> accept = 127.0.0.1:259
> connect = smtps.myisp1.com:465
>
> [smtps-secondacct]
> accept = 127.0.0.1:259
> connect = smtps.myisp2.com:465
>
> Questions:
>
> 1.) a configuration like above with the same "accept" port 259  is NOT possible because
> stunnel does not know to which remote email server he has to connect.
> To distinguish  two different remote email server I always have to select TWO different accept-ports like
>
> [smtps-firstacct]
> accept = 127.0.0.1:259
> connect = smtps.myisp1.com:465
>
> [smtps-secondacct]
> accept = 127.0.0.1:258
> connect = smtps.myisp2.com:465
>
> Correct?

Yes, you want to use different ports in the two service sections.


> 2.) Can I use arbitrary accept-ports like 1242 or 23199 or is there a port range from I have to select one?

You should be able to use any port you wish provided it doesn't produce 
a conflict on your system.


> 3.) Moreover assume I want to make the SSL connection transparent can I select an accept-port 25?

What do you mean by "transparent"?  Selecting port 25 in and of itself 
isn't important, although it may be convenient
in some circumstances since many SMTP in some clients is provisioned for 
port 25 by default.  If you wish to use port 25,
there is nothing to prevent you from doing so.


> 4.) I read somewhere that I have always to specify in email client for POP3/SMTP an address
>
> 127.0.0.1:9999
>
> and NOT
>
> 127.0.0.1:259
>
> in order to connect to local stunnel service. Because local stunnel service is always listening on port 9999.
>
> Is this correct?

No.  Stunnel will listen wherever you tell it to listen.  There is 
nothing magic about port 9999.

>
>
> Thank you
> Ben
>
>
>
>
>
>
>
>
>
> _______________________________________________
> stunnel-users mailing list
> stunnel-users at stunnel.org
> https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users
>

-- 
Attention: This message and all attachments are private and may contain 
information that is confidential and privileged. If you received this 
message in error, please notify the sender by reply email and delete the 
message immediately.



From kxkvi at wi.rr.com  Wed Sep 25 06:03:59 2013
From: kxkvi at wi.rr.com (Thomas Eifert)
Date: Tue, 24 Sep 2013 23:03:59 -0500
Subject: [stunnel-users] One "client=yes" instruction per .conf file
	sufficient?
In-Reply-To: <735263.14877.bm@smtp130.mail.ir2.yahoo.com>
References: <735263.14877.bm@smtp130.mail.ir2.yahoo.com>
Message-ID: <524260AF.8020407@wi.rr.com>


Ben,

While I've seen cases where users attempt to use it globally, in the 
Stunnel manual it's listed as a service-level option.
As such, best to include a "client = yes" in every service section 
unless you want to create a server.

Thomas


On 9/24/2013 6:09 AM, Ben Stover wrote:
> Is one
>
> client=yes
>
> instruction line per conf file enough?
>
> Does is mean all instructions in current .conf file belong to a client configuration
> or does it mean only the following command (=lines below) are intended for client usage?
>
> Ben
>
>
>
>
>
> _______________________________________________
> stunnel-users mailing list
> stunnel-users at stunnel.org
> https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users
>

-- 
Attention: This message and all attachments are private and may contain information that is confidential and privileged. If you received this message in error, please notify the sender by reply email and delete the message immediately.



From kxkvi at wi.rr.com  Wed Sep 25 10:13:03 2013
From: kxkvi at wi.rr.com (Thomas Eifert)
Date: Wed, 25 Sep 2013 03:13:03 -0500
Subject: [stunnel-users] Port assignment in .conf file for local email
 client unique?
In-Reply-To: <903885.98473.bm@smtp138.mail.ir2.yahoo.com>
References: <903885.98473.bm@smtp138.mail.ir2.yahoo.com>
Message-ID: <52429B0F.4070101@wi.rr.com>

On 9/24/2013 6:32 AM, Ben Stover wrote:

> 3.) Moreover assume I want to make the SSL connection transparent can I select an accept-port 25?

If by "transparent" you mean will Stunnel just pass the traffic to the 
remote server without encryption if you accept locally on port 25, then 
no, that's not the way it works.  Stunnel will attempt to negotiate an 
SSL connection with the remote server regardless of which port you 
connect to locally.

Regards,

Thomas

-- 
Attention: This message and all attachments are private and may contain 
information that is confidential and privileged. If you received this 
message in error, please notify the sender by reply email and delete the 
message immediately.

_______________________________________________
stunnel-users mailing list
stunnel-users at stunnel.org
https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users



From gchodos at gmail.com  Wed Sep 25 16:56:26 2013
From: gchodos at gmail.com (Gary Chodos)
Date: Wed, 25 Sep 2013 10:56:26 -0400
Subject: [stunnel-users] Proxy HTTPS via stunnel without any
	certificates on proxy/stunnel box
In-Reply-To: <52424AF7.1070206@trimble.com>
References: <CANDYHM5_BnKDd8Xe3GZfzqBUN4zZk8+uZuho_XuH8Cm1DTtsdg@mail.gmail.com>
 <52424AF7.1070206@trimble.com>
Message-ID: <CANDYHM4eti7O9Mr6__e40dSYv22=uZFdGegYwe5fTXxbOHbDUg@mail.gmail.com>

On Tuesday, September 24, 2013, Jason Haar wrote:

>  On 25/09/13 00:43, Gary Chodos wrote:
>
> We are trying to decide between SNIProxy and stunnel for the following
> task:
>
>  - Client browser hits https://foo.bar.org, which resolves to an IP that
> corresponds to the stunnel machine listening on 443.
>
> - stunnel "forwards" (sorry if this is not the correct technical term) the
> connection to a different machine, specified by a different IP address,
> which is also configured to believe it is foo.bar.org and actually has a
> web server listening on 443 and houses the SSL key/cert.
>
>  What an odd setup. You want to make an HTTPS connection to an IP
> address, but want that to make an HTTPS connection to another IP address,
> but don't want it to house the SSL cert.
>

Correct.


> That isn't possible - an "SSL terminator" requires the cert - otherwise it
> isn't terminating the SSL connection. Why don't you just use a standard TCP
> forwarder instead - won't that do what you want? Don't forget: SSL occurs
> *within* a TCP session - so a standard TCP forwarder can "reroute" the SSL
> transaction without needing to know what it is forwarding (ie no need for
> certs)
>
> You could use xinetd or netcat - tonnes of options
>

Thanks to cluebats from you and the kind folks over on the nginx list, we
went with haproxy in tcpmode.

Thanks,
Gary
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.stunnel.org/pipermail/stunnel-users/attachments/20130925/242b704e/attachment.html>

From dsowen at fugue88.ws  Fri Sep 27 22:00:31 2013
From: dsowen at fugue88.ws (David Owen)
Date: Fri, 27 Sep 2013 14:00:31 -0600 (MDT)
Subject: [stunnel-users] PATCH: multiple SNI options per slave section
Message-ID: <alpine.LNX.2.00.1309271339190.1945@tux.l.fugue88.ws>

Hello and thank you for stunnel!  After switching from my web-server's
built-in SSL support, I now have a much more secure system and SNI,
too!

In stunnel(8), I read this about the sni option:

"sni option can also be specified more than once within a single slave
service."

However, I couldn't get it to work, and reading the source code
verified that only one sni option is tracked per section.

So, I present my patch to allow multiple sni options.  It enables
configurations like these:

  [https]
  ...

  [group1]
  sni = https:a.example.org
  sni = https:b.example.org
  ...

  [group2]
  sni = https:c.example.org
  sni = https:d.example.org
  ...

If you have a naming scheme that doesn't lend itself to the wildcard
matching already supported, this can cut your config size quite a bit.



DETAILS

The sni option for any section was originally tracked in the
section->sni member (a string).  Now, a linked-list of sni options is
added to the section structure, with every sni option being appended
to the end.

For server setup, each slave section walks over its list, splitting
each sni option and adding that slave section to the master's slave
list.  Splitting options and adding slaves to masters works as before,
but now the slave section iterates over a list instead of referencing
a single string.

For client setup, each slave section checks that it has either no sni
options, or exactly one.  Multiple sni options results in an error.
If exactly one option is found, it is copied to the old sni field of
the section struct.  The old sni field has been renamed to
servername_to_request, as it is now used only in client mode, and this
makes its purpose more clear.  When no sni option is found,
servername_to_request is initialized from the protocolHost or connect
options, as before.



I hope this patch is useful to others.  Please let me know how I can
make it acceptable for inclusing in the stunnel distribution.

Thanks,
David
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sni.patch
Type: text/x-diff
Size: 8117 bytes
Desc: 
URL: <http://www.stunnel.org/pipermail/stunnel-users/attachments/20130927/7c508510/attachment.patch>

From bxstover at yahoo.co.uk  Fri Sep 27 22:43:44 2013
From: bxstover at yahoo.co.uk (Ben Stover)
Date: Fri, 27 Sep 2013 22:43:44 +0200
Subject: [stunnel-users] Generic/general mechanism to forward mail
	servername, login, port from client to stunnel
Message-ID: <71148.16454.bm@smtp143.mail.ir2.yahoo.com>

Refering to my last posting I want to ask a related question:

I read in the past somewhere that I can access stunnel from my local email client in more generic way:

At first: stunnel always listens AUTOMATICALLY by default on port 127.0.0.1:9999 für incoming request
and forwards the prepared/modified request to the outside world.

The core parameter are NOT specified in the .conf file but by the User ID which is passed by the
local client to local stunnel service. The syntax is as follows:

userid=<servername>/<remotes-ssl-tls-port>/<loginname>

Example:

userid=pop.mail.yahoo.com/995/myname123

So as soon as stunnel receives at 127.0.0.1:9999 an incoming local connect he accepts the following userid string and tokenize 
it into the three parts. Given these three tokens stunnel is able to connect in the second step the remote mail server
WITHOUT any further need of specification in the .conf file.

Do I remember this correct?

Is this mechanism described somewhere in detail?

Thank you
Ben








From ors at infomed.sld.cu  Mon Sep 30 22:36:59 2013
From: ors at infomed.sld.cu (Odays)
Date: Mon, 30 Sep 2013 16:36:59 -0400
Subject: [stunnel-users] Issue with TCPmon and Stunnel
Message-ID: <5249E0EB.60200@infomed.sld.cu>

Hi all.

I need to configure TCPMon+Stunnel to capture the request/response 
message in the communication with a web services using https.
So I download stunnel-4.56-installer.exe and install it.

In TCPMon  I put that it  listen in port 7777 and redirect to port 1234.

In Stunnel I put this configuration:
client=yes
verify=0
[my-https]
accept  = 127.0.0.1:1234
connect = webservices_server:443
TIMEOUTclose = 0

When i run the scenario I see this log:

2013.09.30 16:12:57 LOG7[8612:6032]: Service [my-https] started
2013.09.30 16:12:57 LOG5[8612:6032]: Service [my-https] accepted 
connection from 127.0.0.1:51759
2013.09.30 16:12:57 LOG7[8612:6032]: SSL state (accept): before/accept 
initialization
*2013.09.30 16:12:57 LOG3[8612:6032]: SSL_accept: 1407609C: 
error:1407609C:SSL routines:SSL23_GET_CLIENT_HELLO:http request*
2013.09.30 16:12:57 LOG5[8612:6032]: Connection reset: 0 byte(s) sent to 
SSL, 0 byte(s) sent to socket
2013.09.30 16:12:57 LOG7[8612:6032]: Local socket (FD=448) closed
2013.09.30 16:12:57 LOG7[8612:6032]: Service [my-https] finished (0 left)

Any idea about this error?

Thanks.


--

Este mensaje le ha llegado mediante el servicio de correo electronico que ofrece Infomed para respaldar el cumplimiento de las misiones del Sistema Nacional de Salud. La persona que envia este correo asume el compromiso de usar el servicio a tales fines y cumplir con las regulaciones establecidas

Infomed: http://www.sld.cu/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.stunnel.org/pipermail/stunnel-users/attachments/20130930/65c27ed2/attachment.html>

From bwilkins at gmail.com  Mon Sep 30 22:42:13 2013
From: bwilkins at gmail.com (Brian Wilkins)
Date: Mon, 30 Sep 2013 16:42:13 -0400
Subject: [stunnel-users] Issue with TCPmon and Stunnel
In-Reply-To: <5249E0EB.60200@infomed.sld.cu>
References: <5249E0EB.60200@infomed.sld.cu>
Message-ID: <CAO_Eq31HK-v7_+SZp5euLeAZpCX7Ftucen+q-H6=h_iD-1qHbQ@mail.gmail.com>

Sounds like a spoof request.


On Mon, Sep 30, 2013 at 4:36 PM, Odays <ors at infomed.sld.cu> wrote:

>  Hi all.
>
> I need to configure TCPMon+Stunnel to capture the request/response message
> in the communication with a web services using https.
> So I download stunnel-4.56-installer.exe and install it.
>
> In TCPMon  I put that it  listen in port 7777 and redirect to port 1234.
>
> In Stunnel I put this configuration:
> client=yes
> verify=0
> [my-https]
> accept  = 127.0.0.1:1234
> connect = webservices_server:443
> TIMEOUTclose = 0
>
> When i run the scenario I see this log:
>
> 2013.09.30 16:12:57 LOG7[8612:6032]: Service [my-https] started
> 2013.09.30 16:12:57 LOG5[8612:6032]: Service [my-https] accepted
> connection from 127.0.0.1:51759
> 2013.09.30 16:12:57 LOG7[8612:6032]: SSL state (accept): before/accept
> initialization
> *2013.09.30 16:12:57 LOG3[8612:6032]: SSL_accept: 1407609C:
> error:1407609C:SSL routines:SSL23_GET_CLIENT_HELLO:http request*
> 2013.09.30 16:12:57 LOG5[8612:6032]: Connection reset: 0 byte(s) sent to
> SSL, 0 byte(s) sent to socket
> 2013.09.30 16:12:57 LOG7[8612:6032]: Local socket (FD=448) closed
> 2013.09.30 16:12:57 LOG7[8612:6032]: Service [my-https] finished (0 left)
>
> Any idea about this error?
>
> Thanks.
>
> _______________________________________________
> stunnel-users mailing list
> stunnel-users at stunnel.org
> https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.stunnel.org/pipermail/stunnel-users/attachments/20130930/7bf6e40c/attachment.html>