Hi!
> I need to know if Stunnel is going to accomplish what i need to do. My home
> ISP blocks protocol HTTP and SSH from coming in so that people cant run
> their own website from home without paying the ISP for a "Business" line
[...]
> Would stunnel allow me to make ssh traffic look like regular https traffic,
> thus allowing me to connect to my server at home so i can do my homework??
Well, yes and no:
Yes: Your SSH traffic will be wrapped in the standard TLS protocol,
which would make it impossible for the ISP to determine what's inside.
They wouldn't be able to determine the actual contents of the traffic,
although they could make good guesses based on the packet metadata
(direction, size, frequency, time between packets, etc.). But they
won't be able to scan packet headers and determine that "hey, this is
SSH, let's block it!".
No: Part of the answer lies above: using statistical methods, it may
be possible to distinguish SSH from something else. The other part
lies in the fact that the ISP doesn't really have to do it - if they
feel like it, they could e.g. block all incoming traffic unless it is
a response to a prior outgoing traffic, or block all incoming traffic
unless it can be determined that it is one of a selected few permitted
protocols.
Likely you won't run into the "No" part of the answer, and in that
case Stunnel will serve nicely (I use it in this scenario, myself).
But you might. In that case, you may want to use something like TCP/IP
Gender Changer (which basically creates a tunnel with reverse
directions), either alone or in combination with Stunnel.
Pepak
1
0
Back in 2013 Bart Dopheide submitted a patch to the mailing list to add
LDAP StartTLS (elevate connection to TLS after initial connection is
initiated) support to the list of supported protocols in protocol.c (
https://www.stunnel.org/pipermail/stunnel-users/2013-November/004437.html).
It doesn't look like this patch was ever accepted into stunnel.
I've run into a similar requirement and have updated the patch to work
against stunnel 5.56. In addition, there are a few other minor changes, the
most significant being as follows. It would appear that Windows Active
Directory servers do not implement the ldap extended response PDU in the
same way as OpenLDAP (see this thread:
https://www.openldap.org/lists/openldap-software/200401/msg00800.html).
With this patch you can specify either "protocol = winldap" or "protocol =
openldap" and have it work either way. I haven't modified the logic of
Bart's original patch as far as OpenLDAP goes, but I have split the code
path where applicable to handle the Windows case.
I am testing this against a virtual Windows Server 2016 Active Directory
instance with self-signed certificates with the following config:
[stunnel.winldap]
client = yes
accept = localhost:3268
connect =mymachine.example.com:3268
protocol = winldap
And the following ldapsearch command:
LDAPTLS_REQCERT=never ldapsearch -Z -h localhost -p 3268 -D
"nginx_bind_dn(a)localdomain.lan" -W -b "dc=localdomain,dc=lan" -s sub
"objectClass=person"
The ldapsearch output returns as expected and I can see in wireshark that
the LDAP_START_TLS_OID request/response happens as it should.
The patch is at the end of this message.
-SG
diff -Nurp a/src/protocol.c b/src/protocol.c
--- a/src/protocol.c 2019-05-15 13:35:16.000000000 -0600
+++ b/src/protocol.c 2019-12-03 13:54:47.536940900 -0700
@@ -64,6 +64,8 @@ NOEXPORT char *pop3_server(CLI *, SERVIC
NOEXPORT char *imap_client(CLI *, SERVICE_OPTIONS *, const PHASE);
NOEXPORT char *imap_server(CLI *, SERVICE_OPTIONS *, const PHASE);
NOEXPORT char *nntp_client(CLI *, SERVICE_OPTIONS *, const PHASE);
+NOEXPORT char *openldap_client(CLI *, SERVICE_OPTIONS *, const PHASE);
+NOEXPORT char *winldap_client(CLI *, SERVICE_OPTIONS *, const PHASE);
NOEXPORT char *connect_server(CLI *, SERVICE_OPTIONS *, const PHASE);
NOEXPORT char *connect_client(CLI *, SERVICE_OPTIONS *, const PHASE);
#ifndef OPENSSL_NO_MD4
@@ -113,6 +115,14 @@ char *protocol(CLI *c, SERVICE_OPTIONS *
return opt->option.client ?
nntp_client(c, opt, phase) :
"The 'nntp' protocol is not supported in the server mode";
+ if(!strcasecmp(opt->protocol, "openldap"))
+ return opt->option.client ?
+ openldap_client(c, opt, phase) :
+ "The 'openldap' protocol is not supported in the server mode";
+ if(!strcasecmp(opt->protocol, "winldap"))
+ return opt->option.client ?
+ winldap_client(c, opt, phase) :
+ "The 'winldap' protocol is not supported in the server mode";
if(!strcasecmp(opt->protocol, "connect"))
return opt->option.client ?
connect_client(c, opt, phase) :
@@ -1119,6 +1129,182 @@ NOEXPORT char *nntp_client(CLI *c, SERVI
return NULL;
}
+/**************************************** LDAP, RFC 2830 */
+uint8_t ldap_startssl_message[0x1d + 2] =
+{
+ 0x30, /* tag = UNIVERSAL SEQUENCE */
+ 0x1d, /* len = 29 (the remaining number of bytes in this message)
*/
+ 0x02, /* messageID */
+ 0x01, /* len = 1 */
+ 0x01, /* value = 1 (this is messageID 1) */
+ /* --- */
+ 0x77, /* protocolOp = APPLICATION (23) (=ExtendedRequest)
+ * 0b01xxxxxx => APPLICATION
+ * 0bxx1xxxxx => ?
+ * 0xxxx10111 => 23
+ */
+ 0x18, /* len = 24 */
+ 0x80, /* type = requstName? */
+ 0x16, /* len = 22 */
+ /* OID: 1.3.6.1.4.1.1466.20037 (=LDAP_START_TLS_OID)*/
+ '1', '.',
+ '3', '.',
+ '6', '.',
+ '1', '.',
+ '4', '.',
+ '1', '.',
+ '1', '4', '6', '6', '.',
+ '2', '0', '0', '3', '7'
+ /* No requestValue, as per RFC2830 (in 2.1: "The requestValue field is
absent") */
+};
+
+typedef enum {
+ LDAP_OPENLDAP,
+ LDAP_WINLDAP
+} LDAP_MODE;
+
+#define LDAP_UNIVERSAL_SEQUENCE 0x30
+#define LDAP_WINLDAP_FOUR_BYTE_LEN_FLAG 0x84
+#define LDAP_RESPONSE_MSG_ID_TYPE_INT 0x02
+#define LDAP_RESPONSE_EXPECTED_MSG_ID_LEN 0x01
+#define LDAP_RESPONSE_EXPECTED_MSG_ID 0x01
+#define LDAP_RESPONSE_EXT_RESP 0x0a
+#define LDAP_RESPONSE_EXT_RESP_APPLICATION 0x78
+#define LDAP_RESPONSE_EXPECTED_ERR_LEN 0x01
+#define LDAP_RESPONSE_SUCCESS 0x00
+
+NOEXPORT char *ldap_client(CLI *c, SERVICE_OPTIONS *opt, const PHASE
phase, const LDAP_MODE ldap_mode) {
+
+ /* thanks to these threads for help with these PDUs
+
https://www.stunnel.org/pipermail/stunnel-users/2013-November/004437.html
+
https://www.openldap.org/lists/openldap-software/200401/msg00800.html */
+
+ uint8_t buffer_8[1];
+ uint32_t buffer_32[1];
+ uint32_t resp_len;
+ uint8_t ldap_response[256];
+ uint8_t *resp_ptr;
+
+ (void)opt; /* squash the unused parameter warning */
+
+ if(phase!=PROTOCOL_MIDDLE)
+ return NULL;
+
+ /* send "Start TLS" request to AD server */
+ s_log(LOG_DEBUG, "Requesting LDAP Start TLS");
+ s_write(c, c->remote_fd.fd, ldap_startssl_message,
(size_t)ldap_startssl_message[1] + 2);
+
+ /* LDAP_UNIVERSAL_SEQUENCE (1 byte) */
+ s_read(c, c->remote_fd.fd, buffer_8, 1);
+ if(buffer_8[0] != LDAP_UNIVERSAL_SEQUENCE) {
+ s_log(LOG_ERR, "start tag is not UNIVERSAL SEQUENCE");
+ throw_exception(c, 1);
+ }
+
+ if(ldap_mode == LDAP_OPENLDAP) {
+ /* OpenLDAP - response length (1 byte) */
+ s_log(LOG_DEBUG, "Reading OpenLDAP message size (1 byte)");
+ s_read(c, c->remote_fd.fd, buffer_8, 1);
+ resp_len = buffer_8;
+
+ } else if(ldap_mode == LDAP_WINLDAP) {
+
+ /* WinLDAP - "response length is 4 bytes" flag -
LDAP_WINLDAP_FOUR_BYTE_LEN_FLAG (1-byte) */
+ s_read(c, c->remote_fd.fd, buffer_8, 1);
+ if(buffer_8[0] != LDAP_WINLDAP_FOUR_BYTE_LEN_FLAG) {
+ s_log(LOG_ERR, "LDAP message length flag is an unexpected
value");
+ throw_exception(c, 1);
+ }
+
+ /* WinLDAP - response length (4 bytes, network byte order) */
+ s_log(LOG_DEBUG, "Reading WinLDAP message size (4 bytes)");
+ s_read(c, c->remote_fd.fd, buffer_32, 4);
+ resp_len = ntohl(buffer_32[0]);
+
+ } else {
+ s_log(LOG_ERR, "Unsupported LDAP mode");
+ throw_exception(c, 1);
+ }
+
+ /* LDAP response message */
+ s_log(LOG_DEBUG, "Reading LDAP message (%u byte(s))", resp_len);
+ s_read(c, c->remote_fd.fd, ldap_response, resp_len);
+
+ resp_ptr = &ldap_response[0];
+
+ /* LDAP_RESPONSE_MSG_ID_TYPE_INT - 1 byte */
+ if(*resp_ptr != LDAP_RESPONSE_MSG_ID_TYPE_INT) {
+ s_log(LOG_ERR, "LDAP response has an incorrect message ID type");
+ throw_exception(c, 1);
+ }
+ resp_ptr++;
+
+ /* LDAP_RESPONSE_EXPECTED_MSG_ID_LEN - 1 byte */
+ if(*resp_ptr != LDAP_RESPONSE_EXPECTED_MSG_ID_LEN) {
+ s_log(LOG_ERR, "LDAP response has an unexpected message ID
length");
+ throw_exception(c, 1);
+ }
+ resp_ptr++;
+
+ /* LDAP_RESPONSE_EXPECTED_MSG_ID - 1 byte */
+ if(*resp_ptr != LDAP_RESPONSE_EXPECTED_MSG_ID) {
+ s_log(LOG_ERR, "LDAP response has an unexpected message ID");
+ throw_exception(c, 1);
+ }
+ resp_ptr++;
+
+ /* LDAP_RESPONSE_EXT_RESP_APPLICATION - 1 byte */
+ if(*resp_ptr != LDAP_RESPONSE_EXT_RESP_APPLICATION) {
+ s_log(LOG_ERR, "LDAP response protocolOp is not APPLICATION");
+ throw_exception(c, 1);
+ }
+ resp_ptr++;
+
+ if(ldap_mode == LDAP_WINLDAP) {
+ /* WinLDAP - "response length is 4 bytes" flag -
LDAP_WINLDAP_FOUR_BYTE_LEN_FLAG (1-byte) */
+ if(*resp_ptr != LDAP_WINLDAP_FOUR_BYTE_LEN_FLAG) {
+ s_log(LOG_ERR, "LDAP extendedResp length flag is an unexpected
value");
+ throw_exception(c, 1);
+ }
+ /* WinLDAP - extended response message length (4-bytes) */
+ resp_ptr += 5;
+
+ } else {
+ /* OpenLDAP - extended response message length (1-byte) */
+ resp_ptr++;
+ }
+
+ /* LDAP_RESPONSE_EXT_RESP - 1 byte */
+ if(*resp_ptr != LDAP_RESPONSE_EXT_RESP) {
+ s_log(LOG_ERR, "LDAP response type is not EXT_RESP");
+ throw_exception(c, 1);
+ }
+ resp_ptr++;
+
+ /* LDAP_RESPONSE_EXT_RESP - 1 byte */
+ if(*resp_ptr != LDAP_RESPONSE_EXPECTED_ERR_LEN) {
+ s_log(LOG_ERR, "LDAP response has an unexpected error code
length");
+ throw_exception(c, 1);
+ }
+ resp_ptr++;
+
+ if(*resp_ptr != LDAP_RESPONSE_SUCCESS) {
+ s_log(LOG_ERR, "LDAP response has indicated an error (%u)",
*resp_ptr);
+ throw_exception(c, 1);
+ }
+
+ return NULL;
+}
+
+
+NOEXPORT char *openldap_client(CLI *c, SERVICE_OPTIONS *opt, const PHASE
phase) {
+ return ldap_client(c, opt, phase, LDAP_OPENLDAP);
+}
+
+NOEXPORT char *winldap_client(CLI *c, SERVICE_OPTIONS *opt, const PHASE
phase) {
+ return ldap_client(c, opt, phase, LDAP_WINLDAP);
+}
+
/**************************************** connect */
NOEXPORT char *connect_server(CLI *c, SERVICE_OPTIONS *opt, const PHASE
phase) {
1
1
Hi!
Does Stunnel support static-linked engines for OpenSSL? From my
experiments, my guess would be that it doesn't, but I may be
overlooking something and would welcome a confirmation.
Why I need it: During development of an urelated app, after many many
failed attempts, I finally managed to get OpenSSL 1.1.x working with a
CAPI engine - but the only functional setup involved CAPI built
directly into libcrypto. Every other setup, in both Visual Studio and
MinGW, led to some problem or another. I would love to extend this
success to my Stunnel setup, where I am now forced to stick with
version 5.49 because the newer versions use OpenSSL 1.1.x which simply
doesn't seem to be able to function correctly with the dynamic CAPI
engine.
What I need from Stunnel, basically, is for it to try to use
ENGINE_by_id('capi') first and only when that fails, attempt to load a
dynamic engine using ENGINE_by_id('dynamic') and the necessary
ENGINE_ctrl_cmd_string commands. I can build a functional static-built
OpenSSL libraries myself.
If Stunnel wanted to incorporate that, I am all for it, provided that
there is some way of specifying whether a static engine or a dynamic
engine is preferred. My Configure command is:
perl Configure shared enable-static-engine enable-zlib
--with-zlib-include=C:\Zlib --with-zlib-lib=C:\Zlib\zlib.lib VC-WIN64A
Pepak
1
0
Re: [stunnel-users] stunnel 5.55 - - - SSL_connect: Peer suddenly disconnected
by Flo Rance 06 Dec '19
by Flo Rance 06 Dec '19
06 Dec '19
The full logs of both sides would still be useful.
Regards,
Flo
On Fri, 6 Dec 2019 at 09:48, simona vittori <svittori(a)gmail.com> wrote:
> Hi,
> port 41521 is the port of stunnel server istance that then redirect
> connection in clear on port 1521 of the listener.
>
> That's all
>
> Thanks
>
> Simona
>
> Il giorno ven 6 dic 2019 alle ore 09:37 Flo Rance <trourance(a)gmail.com>
> ha scritto:
>
>> Hi,
>>
>> The full logs of the client would be useful.
>>
>> What are you trying to connect to (on port 41521) ?
>>
>> Regards,
>> Flo
>>
>> On Thu, 5 Dec 2019 at 12:44, simona vittori <svittori(a)gmail.com> wrote:
>>
>>> Hello,
>>>
>>> I have stunnel v 5.55 on linux machine client e linux machine db server,
>>> Red Hat Enterprise Linux Server release 6.6. I have noticed that there are
>>> many many diconnections by side client (at the bottom of the page). Why
>>> there is this behavior?
>>>
>>> This is the configuration file of client machine:
>>>
>>> cert = /opt/stunnel-5.55/etc/stunnel/stunnel.pem
>>> verify = 3
>>> setuid = stunnel
>>>
>>> CAfile = /opt/stunnel-5.55/var/certs.pem
>>>
>>> pid = /opt/stunnel-5.55/var/lib/stunnel/stunnel_client.pid
>>>
>>> socket = l:TCP_NODELAY=1
>>> socket = r:TCP_NODELAY=1
>>>
>>> sslVersion = TLSv1
>>>
>>> TIMEOUTconnect = 30
>>> failover = rr
>>>
>>> ciphers = ECDH@STRENGTH:DH@STRENGTH:HIGH:!RC4:!MD5:!DES:!aNULL:!eNULL
>>>
>>> debug = 7
>>> output = /opt/stunnel-5.55/var/stunnel.log
>>>
>>> client = yes
>>>
>>> [connessione_a_EMPRMDB1-DB2]
>>> accept=127.0.0.1:10001
>>> connect=10.56.213.70:41521
>>> connect=10.56.213.72:41521
>>>
>>>
>>> #######################################################################################
>>>
>>> Dec 5 12:31:42 EMWBPAPP2b stunnel: []:LOG3[15001]: SSL_connect: Peer
>>> suddenly disconnected
>>> Dec 5 12:31:52 EMWBPAPP2b stunnel: []:LOG3[15007]: SSL_connect: Peer
>>> suddenly disconnected
>>> Dec 5 12:32:13 EMWBPAPP2b stunnel: []:LOG3[15013]: SSL_connect: Peer
>>> suddenly disconnected
>>> Dec 5 12:32:13 EMWBPAPP2b stunnel: []:LOG3[15014]: SSL_connect: Peer
>>> suddenly disconnected
>>> Dec 5 12:32:22 EMWBPAPP2b stunnel: []:LOG3[15019]: SSL_connect: Peer
>>> suddenly disconnected
>>> Dec 5 12:32:23 EMWBPAPP2b stunnel: []:LOG3[15021]: SSL_connect: Peer
>>> suddenly disconnected
>>> Dec 5 12:32:23 EMWBPAPP2b stunnel: []:LOG3[15023]: SSL_connect: Peer
>>> suddenly disconnected
>>> Dec 5 12:32:24 EMWBPAPP2b stunnel: []:LOG3[15024]: SSL_connect: Peer
>>> suddenly disconnected
>>> Dec 5 12:32:44 EMWBPAPP2b stunnel: []:LOG3[15033]: SSL_connect: Peer
>>> suddenly disconnected
>>> Dec 5 12:32:45 EMWBPAPP2b stunnel: []:LOG3[15035]: SSL_connect: Peer
>>> suddenly disconnected
>>> Dec 5 12:32:55 EMWBPAPP2b stunnel: []:LOG3[15041]: SSL_connect: Peer
>>> suddenly disconnected
>>> Dec 5 12:34:04 EMWBPAPP2b stunnel: []:LOG3[15062]: SSL_connect: Peer
>>> suddenly disconnected
>>> Dec 5 12:34:05 EMWBPAPP2b stunnel: []:LOG3[15063]: SSL_connect: Peer
>>> suddenly disconnected
>>> Dec 5 12:34:06 EMWBPAPP2b stunnel: []:LOG3[15065]: SSL_connect: Peer
>>> suddenly disconnected
>>> Dec 5 12:34:18 EMWBPAPP2b stunnel: []:LOG3[15069]: SSL_connect: Peer
>>> suddenly disconnected
>>>
>>> #####################################################################à
>>>
>>> Thank for your help
>>>
>>> Simona
>>> _______________________________________________
>>> stunnel-users mailing list
>>> stunnel-users(a)stunnel.org
>>> https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users
>>>
>>
1
0
Hello,
I have stunnel v 5.55 on linux machine client e linux machine db server,
Red Hat Enterprise Linux Server release 6.6. I have noticed that there are
many many diconnections by side client (at the bottom of the page). Why
there is this behavior?
This is the configuration file of client machine:
cert = /opt/stunnel-5.55/etc/stunnel/stunnel.pem
verify = 3
setuid = stunnel
CAfile = /opt/stunnel-5.55/var/certs.pem
pid = /opt/stunnel-5.55/var/lib/stunnel/stunnel_client.pid
socket = l:TCP_NODELAY=1
socket = r:TCP_NODELAY=1
sslVersion = TLSv1
TIMEOUTconnect = 30
failover = rr
ciphers = ECDH@STRENGTH:DH@STRENGTH:HIGH:!RC4:!MD5:!DES:!aNULL:!eNULL
debug = 7
output = /opt/stunnel-5.55/var/stunnel.log
client = yes
[connessione_a_EMPRMDB1-DB2]
accept=127.0.0.1:10001
connect=10.56.213.70:41521
connect=10.56.213.72:41521
#######################################################################################
Dec 5 12:31:42 EMWBPAPP2b stunnel: []:LOG3[15001]: SSL_connect: Peer
suddenly disconnected
Dec 5 12:31:52 EMWBPAPP2b stunnel: []:LOG3[15007]: SSL_connect: Peer
suddenly disconnected
Dec 5 12:32:13 EMWBPAPP2b stunnel: []:LOG3[15013]: SSL_connect: Peer
suddenly disconnected
Dec 5 12:32:13 EMWBPAPP2b stunnel: []:LOG3[15014]: SSL_connect: Peer
suddenly disconnected
Dec 5 12:32:22 EMWBPAPP2b stunnel: []:LOG3[15019]: SSL_connect: Peer
suddenly disconnected
Dec 5 12:32:23 EMWBPAPP2b stunnel: []:LOG3[15021]: SSL_connect: Peer
suddenly disconnected
Dec 5 12:32:23 EMWBPAPP2b stunnel: []:LOG3[15023]: SSL_connect: Peer
suddenly disconnected
Dec 5 12:32:24 EMWBPAPP2b stunnel: []:LOG3[15024]: SSL_connect: Peer
suddenly disconnected
Dec 5 12:32:44 EMWBPAPP2b stunnel: []:LOG3[15033]: SSL_connect: Peer
suddenly disconnected
Dec 5 12:32:45 EMWBPAPP2b stunnel: []:LOG3[15035]: SSL_connect: Peer
suddenly disconnected
Dec 5 12:32:55 EMWBPAPP2b stunnel: []:LOG3[15041]: SSL_connect: Peer
suddenly disconnected
Dec 5 12:34:04 EMWBPAPP2b stunnel: []:LOG3[15062]: SSL_connect: Peer
suddenly disconnected
Dec 5 12:34:05 EMWBPAPP2b stunnel: []:LOG3[15063]: SSL_connect: Peer
suddenly disconnected
Dec 5 12:34:06 EMWBPAPP2b stunnel: []:LOG3[15065]: SSL_connect: Peer
suddenly disconnected
Dec 5 12:34:18 EMWBPAPP2b stunnel: []:LOG3[15069]: SSL_connect: Peer
suddenly disconnected
#####################################################################à
Thank for your help
Simona
2
1
Ajiq,
On 12/3/19 09:13, Ajjq . wrote:
> Hi Christopher:
>
> You are right. I needed
> C:> TELNET LOCALHOST 80 and expect to be connected to sub.dominio.com:443
>
> I modified stunnel.conf with client=yes. I am including stunnel.con and
> log.
>
> I created the service Stunnel service, but when I start it, I get this
> error message.
>
> [Stunnel server is down due to an error. You need to exit and correct
the problem. Click OK to see the error log window.]
The screenshot shows an error "bind: Address already in use".
Do you have stunnel running twice at once?
Please stop stunnel, delete your log file, then start it again. Post the
resulting log file to the mailing list.
-chris
>
>
> stunnel.conf
>
> debug = 7
> output = stunnel3.log
>
> ; TLS front-end to a web server
> [https]
> client=yes
> accept = 127.0.0.1:80
> connect = subd.dominio.com:443
> cert = stunnel.pem
> TIMEOUTclose = 0
Is TIMEOPUTclose=0 actually on one line? That might be a syntax error.
-chris
2
1
Hi
I need to enable a tunnel_out for UTL_HTTP from http:// to https://
I installed stunnel 5.34 win32 in a windows 2008 server.
I am including my stunnel.conf y log file (debug=7)
As you can see in the log file, I get this error:
2019.12.01 14:08:12 LOG3[7]: SSL_accept: 1407609C: error:1407609C:SSL routines:SSL23_GET_CLIENT_HELLO:http request
Could you help me please?
MY stunnel.conf---
debug = 7
output = stunnel.log
[https]
accept = 127.0.0.1:80
connect = sub.dominio.com:443
cert = stunnel.pem
TIMEOUTclose = 0
This version has openssl[cid:b6de9085-07c4-43d0-b772-bb9beb37c2ac]
MY LOG---
2019.12.01 14:00:37 LOG7[cron]: Cron thread initialized
2019.12.01 14:00:37 LOG7[main]: No limit detected for the number of clients
2019.12.01 14:00:37 LOG5[main]: stunnel 5.34 on x86-pc-msvc-1500 platform
2019.12.01 14:00:37 LOG5[main]: Compiled/running with OpenSSL 1.0.2h-fips 3 May 2016
2019.12.01 14:00:37 LOG5[main]: Threading:WIN32 Sockets:SELECT,IPv6 TLS:ENGINE,FIPS,OCSP,PSK,SNI
2019.12.01 14:00:37 LOG7[main]: errno: (*_errno())
2019.12.01 14:00:37 LOG7[ui]: GUI message loop initialized
2019.12.01 14:00:37 LOG5[main]: Reading configuration from file stunnel.conf
2019.12.01 14:00:37 LOG5[main]: UTF-8 byte order mark detected
2019.12.01 14:00:37 LOG5[main]: FIPS mode disabled
2019.12.01 14:00:37 LOG7[main]: Compression disabled
2019.12.01 14:00:37 LOG7[main]: Snagged 64 random bytes from C:/.rnd
2019.12.01 14:00:37 LOG7[main]: Wrote 1024 new random bytes to C:/.rnd
2019.12.01 14:00:37 LOG7[main]: PRNG seeded successfully
2019.12.01 14:00:37 LOG6[main]: Initializing service [https]
2019.12.01 14:00:38 LOG6[main]: Loading certificate from file: stunnel.pem
2019.12.01 14:00:38 LOG6[main]: Certificate loaded from file: stunnel.pem
2019.12.01 14:00:38 LOG6[main]: Loading private key from file: stunnel.pem
2019.12.01 14:00:38 LOG6[main]: Private key loaded from file: stunnel.pem
2019.12.01 14:00:38 LOG7[main]: Private key check succeeded
2019.12.01 14:00:38 LOG7[main]: DH initialization
2019.12.01 14:00:38 LOG7[main]: Could not load DH parameters from stunnel.pem
2019.12.01 14:00:38 LOG6[main]: Using dynamic DH parameters
2019.12.01 14:00:38 LOG7[main]: ECDH initialization
2019.12.01 14:00:38 LOG7[main]: ECDH initialized with curve prime256v1
2019.12.01 14:00:38 LOG7[main]: SSL options: 0x03004004 (+0x03004000, -0x00000000)
2019.12.01 14:00:38 LOG5[main]: Configuration successful
2019.12.01 14:00:38 LOG7[main]: Listening file descriptor created (FD=352)
2019.12.01 14:00:38 LOG7[main]: Service [https] (FD=352) bound to 127.0.0.1:80
2019.12.01 14:00:59 LOG7[main]: Found 1 ready file descriptor(s)
2019.12.01 14:00:59 LOG7[main]: FD=260 ifds=r-x ofds=r--
2019.12.01 14:00:59 LOG7[main]: Dispatching signals from the signal pipe
2019.12.01 14:00:59 LOG7[main]: Processing SIGNAL_RELOAD_CONFIG
2019.12.01 14:00:59 LOG5[main]: Reading configuration from file stunnel.conf
2019.12.01 14:00:59 LOG5[main]: UTF-8 byte order mark detected
2019.12.01 14:00:59 LOG5[main]: FIPS mode disabled
2019.12.01 14:00:59 LOG7[main]: Compression disabled
2019.12.01 14:00:59 LOG7[main]: Snagged 64 random bytes from C:/.rnd
2019.12.01 14:00:59 LOG7[main]: Wrote 1024 new random bytes to C:/.rnd
2019.12.01 14:00:59 LOG7[main]: PRNG seeded successfully
2019.12.01 14:00:59 LOG6[main]: Initializing service [https]
2019.12.01 14:00:59 LOG6[main]: Loading certificate from file: stunnel.pem
2019.12.01 14:00:59 LOG6[main]: Certificate loaded from file: stunnel.pem
2019.12.01 14:00:59 LOG6[main]: Loading private key from file: stunnel.pem
2019.12.01 14:00:59 LOG6[main]: Private key loaded from file: stunnel.pem
2019.12.01 14:00:59 LOG7[main]: Private key check succeeded
2019.12.01 14:00:59 LOG7[main]: DH initialization
2019.12.01 14:00:59 LOG7[main]: Could not load DH parameters from stunnel.pem
2019.12.01 14:00:59 LOG6[main]: Using dynamic DH parameters
2019.12.01 14:00:59 LOG7[main]: ECDH initialization
2019.12.01 14:00:59 LOG7[main]: ECDH initialized with curve prime256v1
2019.12.01 14:00:59 LOG7[main]: SSL options: 0x03004004 (+0x03004000, -0x00000000)
2019.12.01 14:00:59 LOG5[main]: Configuration successful
2019.12.01 14:00:59 LOG7[main]: Closing service [https]
2019.12.01 14:00:59 LOG7[main]: Service [https] closed (FD=352)
2019.12.01 14:00:59 LOG7[main]: Service [https] closed
2019.12.01 14:00:59 LOG7[main]: Listening file descriptor created (FD=352)
2019.12.01 14:00:59 LOG7[main]: Service [https] (FD=352) bound to 127.0.0.1:80
2019.12.01 14:00:59 LOG7[main]: Signal pipe is empty
2019.12.01 14:01:37 LOG6[cron]: Executing cron jobs
2019.12.01 14:01:37 LOG5[cron]: Updating DH parameters
2019.12.01 14:01:37 LOG7[main]: Found 1 ready file descriptor(s)
2019.12.01 14:01:37 LOG7[main]: FD=260 ifds=r-x ofds=---
2019.12.01 14:01:37 LOG7[main]: Service [https] accepted (FD=420) from 127.0.0.1:56581
2019.12.01 14:01:37 LOG7[main]: Creating a new thread
2019.12.01 14:01:37 LOG7[main]: New thread created
2019.12.01 14:01:37 LOG7[0]: Service [https] started
2019.12.01 14:01:37 LOG5[0]: Service [https] accepted connection from 127.0.0.1:56581
2019.12.01 14:01:37 LOG7[0]: SSL state (accept): before/accept initialization
2019.12.01 14:01:37 LOG7[main]: Found 1 ready file descriptor(s)
2019.12.01 14:01:37 LOG7[main]: FD=260 ifds=r-x ofds=---
2019.12.01 14:01:37 LOG7[main]: Service [https] accepted (FD=440) from 127.0.0.1:56582
2019.12.01 14:01:37 LOG7[main]: Creating a new thread
2019.12.01 14:01:37 LOG7[main]: New thread created
2019.12.01 14:01:37 LOG7[1]: Service [https] started
2019.12.01 14:01:37 LOG5[1]: Service [https] accepted connection from 127.0.0.1:56582
2019.12.01 14:01:37 LOG7[1]: SSL state (accept): before/accept initialization
2019.12.01 14:01:37 LOG3[0]: SSL_accept: 1407609C: error:1407609C:SSL routines:SSL23_GET_CLIENT_HELLO:http request
2019.12.01 14:01:37 LOG5[0]: Connection reset: 0 byte(s) sent to SSL, 0 byte(s) sent to socket
2019.12.01 14:01:37 LOG7[0]: Local descriptor (FD=420) closed
2019.12.01 14:01:37 LOG7[0]: Service [https] finished (1 left)
2019.12.01 14:01:37 LOG3[1]: SSL_accept: 1407609C: error:1407609C:SSL routines:SSL23_GET_CLIENT_HELLO:http request
2019.12.01 14:01:37 LOG5[1]: Connection reset: 0 byte(s) sent to SSL, 0 byte(s) sent to socket
2019.12.01 14:01:37 LOG7[1]: Local descriptor (FD=440) closed
2019.12.01 14:01:37 LOG7[1]: Service [https] finished (0 left)
2019.12.01 14:01:37 LOG7[main]: Found 1 ready file descriptor(s)
2019.12.01 14:01:37 LOG7[main]: FD=260 ifds=r-x ofds=---
2019.12.01 14:01:37 LOG7[main]: Service [https] accepted (FD=448) from 127.0.0.1:56583
2019.12.01 14:01:37 LOG7[main]: Creating a new thread
2019.12.01 14:01:37 LOG7[main]: New thread created
2019.12.01 14:01:37 LOG7[2]: Service [https] started
2019.12.01 14:01:37 LOG5[2]: Service [https] accepted connection from 127.0.0.1:56583
2019.12.01 14:01:37 LOG7[2]: SSL state (accept): before/accept initialization
2019.12.01 14:01:37 LOG3[2]: SSL_accept: 1407609C: error:1407609C:SSL routines:SSL23_GET_CLIENT_HELLO:http request
2019.12.01 14:01:37 LOG5[2]: Connection reset: 0 byte(s) sent to SSL, 0 byte(s) sent to socket
2019.12.01 14:01:37 LOG7[2]: Local descriptor (FD=448) closed
2019.12.01 14:01:37 LOG7[2]: Service [https] finished (0 left)
2019.12.01 14:01:37 LOG7[main]: Found 1 ready file descriptor(s)
2019.12.01 14:01:37 LOG7[main]: FD=260 ifds=r-x ofds=---
2019.12.01 14:01:37 LOG7[main]: Service [https] accepted (FD=452) from 127.0.0.1:56584
2019.12.01 14:01:37 LOG7[main]: Creating a new thread
2019.12.01 14:01:37 LOG7[main]: New thread created
2019.12.01 14:01:37 LOG7[3]: Service [https] started
2019.12.01 14:01:37 LOG5[3]: Service [https] accepted connection from 127.0.0.1:56584
2019.12.01 14:01:37 LOG7[3]: SSL state (accept): before/accept initialization
2019.12.01 14:01:37 LOG3[3]: SSL_accept: 1407609C: error:1407609C:SSL routines:SSL23_GET_CLIENT_HELLO:http request
2019.12.01 14:01:37 LOG5[3]: Connection reset: 0 byte(s) sent to SSL, 0 byte(s) sent to socket
2019.12.01 14:01:37 LOG7[3]: Local descriptor (FD=452) closed
2019.12.01 14:01:37 LOG7[3]: Service [https] finished (0 left)
Thanks in advance.
2
1