- stunnel-users - stunnel.org

error invalid stunnel.conf - No limit of clients
by Christian Huber 09 Dec '13

09 Dec '13

Hi, I just installed stunnel for my email programm courier. I edited the stunnel.conf as followed but am unfortunatly becoming the message from stunnel: invalid stunnel.conf No limit detected for the number of clients stunnel 4.56 on x86-pc-msvc-1500 platform Compiled/running with OpenSSL 1.0.1e-fips 11 Feb 2013 Threading:WIN32 Sockets:SELECT,IPv6 SSL:ENGINE,OCSP,FIPS Reading configuration from file stunnel.conf FIPS_mode_set: 2D07808C: error:2D07808C:FIPS routines:FIPS_module_mode_set:unsupported platform Line 11: "[POP3 T-Online]": Failed to initialize SSL Server is down my stunnel.conf is as followed: # GLOBAL OPTIONS client = yes output = stunnel-log.txt debug=4 taskbar = yes # SERVICE-LEVEL OPTIONS [POP3 T-Online] accept = 127.0.0.1:108 connect = securepop.t-online.de:995 [SMTP T-Online] accept = 127.0.0.1:107 connect = securesmtp.t-online.de:587 [POP3 web.de] accept = 127.0.0.1:106 connect = pop3.web.de:995 [SMTP web.de] accept = 127.0.0.1:105 connect = smtp.web.de:587 [POP3 STRATO] accept = 127.0.0.1:104 connect = pop3.strato.de:995 [SMTP STRATO] accept = 127.0.0.1:103 connect = smtp.strato.de:465 [POP3 GMX ] accept = 127.0.0.1:102 connect = pop.gmx.net:995 [SMTP GMX ] accept = 127.0.0.1:101 connect = mail.gmx.net:465 ___________________ Would be nice if someone could tell me what is wrong! Greetings Christian Huber

3 3

t-online, web.de E-mail with Courier
by Christian Huber 08 Dec '13

08 Dec '13

Hi, stunnel is now working with the fips=no global option without error! My e-mail programm courier is working with the servers from strato and gmx! But with t-online it is not working at the moment! I can not login into the pop3 server! >From courier I get the message: Sendrecv.c[229] Pop3.dll recv() failed WINSOCK Error: Connection reset. (The mail server terminated the connection. With web.de I can login into the pop3 server and receive mails. But sending mails is not sucessfull! >From courier I get the message: Sendrecv.c[188] Smtp.dll recv(MSG_PEEK) failed WINSOCK Error: Connection reset. (The mail server terminated the connection. Would be nice if someone has a solution! My stunnel.conf: # GLOBAL OPTIONS client = yes fips=no output = stunnel-log.txt debug=4 taskbar = yes # SERVICE-LEVEL OPTIONS [POP3 T-Online] accept = 127.0.0.1:108 connect = securepop.t-online.de:995 [SMTP T-Online] accept = 127.0.0.1:107 connect = securesmtp.t-online.de:587 [POP3 web.de] accept = 127.0.0.1:106 connect = pop3.web.de:995 [SMTP web.de] accept = 127.0.0.1:105 connect = smtp.web.de:587 [POP3 STRATO] accept = 127.0.0.1:104 connect = pop3.strato.de:995 [SMTP STRATO] accept = 127.0.0.1:103 connect = smtp.strato.de:465 [POP3 GMX ] accept = 127.0.0.1:102 connect = pop.gmx.net:995 [SMTP GMX ] accept = 127.0.0.1:101 connect = mail.gmx.net:465

1 0

stunnel domain name resolution bug
by David Slachta 07 Dec '13

07 Dec '13

I'm new to the mailing lists so I hope it's the correct way to report a bug. There's an issue with resolving domain names. I'm connecting an stunnel client to a server that sits on a computer which IP address is dynamic. Therefore I'm using a dyndns for the IP address of the server. When the IP address of the server is changed, the stunnel client doesn't update the name resolution of the dyndns name and tries to connect to the old IP which is of course unsuccessful. This can be resolved only by exiting and starting stunnel client again when a new domain name resolution is made. Would it be possible to add a functionality to the stunnel that wouldn't cache the name resolution but try to resolve the domain names every time there's a connection request? I'm using a Windows OS for both server and client, not sure if that makes a difference. Thanks! David

2 1

Re: [stunnel-users] stunnel domain name resolution bug
by Brian Wilkins 06 Dec '13

06 Dec '13

Sent you traffic from Sept 19th from Trojnara. May be helpful On Dec 6, 2013 6:11 PM, "Brian Wilkins" <bwilkins(a)gmail.com> wrote: > See my forward > On Dec 6, 2013 5:53 PM, "David Slachta" <elpin(a)volny.cz> wrote: > >> I'm new to the mailing lists so I hope it's the correct way to report a >> bug. >> >> There's an issue with resolving domain names. I'm connecting an stunnel >> client to a server that sits on a computer which IP address is dynamic. >> Therefore I'm using a dyndns for the IP address of the server. When the IP >> address of the server is changed, the stunnel client doesn't update the >> name resolution of the dyndns name and tries to connect to the old IP which >> is of course unsuccessful. This can be resolved only by exiting and >> starting stunnel client again when a new domain name resolution is made. >> >> Would it be possible to add a functionality to the stunnel that wouldn't >> cache the name resolution but try to resolve the domain names every time >> there's a connection request? >> >> I'm using a Windows OS for both server and client, not sure if that makes >> a difference. >> >> Thanks! >> David >> >> _______________________________________________ >> stunnel-users mailing list >> stunnel-users(a)stunnel.org >> https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users >> >>

1 0

Hostname verification, support for, and patches
by fslama＠comcast.net 06 Dec '13

06 Dec '13

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

4 3

setup stunnel problem
by edu.bit.es＠gmail.com 20 Nov '13

20 Nov '13

Hi everybody, I'm absolutely new in stunnel. I came around because of a post in the google forums about making Symantec System Recovery mail through smtp.gmail.com. Symantec is not capable of doing SSL/TLS so I need a solution like stunnel. But I've an issue: it doesn't seem to work :) I installed the program ok, and configured in the following way: cert=stunnel.pem socket = l:TCP_NODELAY=1 socket= r:TCP_NODELAY=1 [gmail-smtp] client=yes accept:127.0.0.1:25 connect= smtp.gamil.com:465 EOF The server is listening on port 127.0.0.1:25 but when I do a telnet to that port gives an error and doesn't seem to tunnel me to smtp.gmail.com. On the other hand, I configured outlook to use that tunnel but gives an error stating it can reach the smtp server. What am I doing wrong? Should I change the TLS version? Best regards and thanks in advance.

2 7

Stunnel with gmail not working on RHEL 6.4
by André Luís 17 Nov '13

17 Nov '13

Hello, I am trying to setup stunnel to send email using gmail smtp server trough Oracle Database. I first tested on my windows machine. I installed and configured stunnel and it worked fine.But now I tried to do the same on our server (RHEL 6.4) and it doesn't work. I can successfuly telnet the 25 port: [root@server1 stunnel]# telnet localhost 25Trying 127.0.0.1...Connected to localhost.Escape character is '^]'.220 mx.google.com ESMTP so2sm18740691pbc.5 - gsmtp When I send the email, i receive this error: SMTP permanent error: 534 5.7.14 54 ef10sm21262349pac.1 - gsmtp anyone have any idea? the stunnel.conf: pid = /stunnel.pidoutput = /var/log/stunnel.logcompression = zlibsslVersion = alloptions = NO_SSLv2debug = 7 [gmail-smtp]client = yesaccept = localhost:25connect = smtp.gmail.com:465 Here is the Stunnel log:2013.11.17 15:58:34 LOG7[23729:139952118699968]: gmail-smtp accepted FD=13 from 127.0.0.1:560892013.11.17 15:58:34 LOG7[23729:139952118695680]: gmail-smtp started2013.11.17 15:58:34 LOG7[23729:139952118695680]: FD 13 in non-blocking mode2013.11.17 15:58:34 LOG7[23729:139952118695680]: Waiting for a libwrap process2013.11.17 15:58:34 LOG7[23729:139952118695680]: Acquired libwrap process #02013.11.17 15:58:34 LOG7[23729:139952118695680]: Releasing libwrap process #02013.11.17 15:58:34 LOG7[23729:139952118695680]: Released libwrap process #02013.11.17 15:58:34 LOG7[23729:139952118695680]: gmail-smtp permitted by libwrap from 127.0.0.1:560892013.11.17 15:58:34 LOG5[23729:139952118695680]: gmail-smtp accepted connection from 127.0.0.1:560892013.11.17 15:58:34 LOG7[23729:139952118695680]: FD 14 in non-blocking mode2013.11.17 15:58:34 LOG6[23729:139952118695680]: connect_blocking: connecting 74.125.129.108:4652013.11.17 15:58:34 LOG7[23729:139952118695680]: connect_blocking: s_poll_wait 74.125.129.108:465: waiting 10 seconds2013.11.17 15:58:34 LOG5[23729:139952118695680]: connect_blocking: connected 74.125.129.108:4652013.11.17 15:58:34 LOG5[23729:139952118695680]: gmail-smtp connected remote server from 172.31.22.161:510672013.11.17 15:58:34 LOG7[23729:139952118695680]: Remote FD=14 initialized2013.11.17 15:58:34 LOG7[23729:139952118695680]: SSL state (connect): before/connect initialization2013.11.17 15:58:34 LOG7[23729:139952118695680]: SSL state (connect): SSLv2/v3 write client hello A2013.11.17 15:58:34 LOG7[23729:139952118695680]: SSL state (connect): SSLv3 read server hello A2013.11.17 15:58:34 LOG7[23729:139952118695680]: SSL state (connect): SSLv3 read server certificate A2013.11.17 15:58:34 LOG7[23729:139952118695680]: SSL state (connect): SSLv3 read server done A2013.11.17 15:58:34 LOG7[23729:139952118695680]: SSL state (connect): SSLv3 write client key exchange A2013.11.17 15:58:34 LOG7[23729:139952118695680]: SSL state (connect): SSLv3 write change cipher spec A2013.11.17 15:58:34 LOG7[23729:139952118695680]: SSL state (connect): SSLv3 write finished A2013.11.17 15:58:34 LOG7[23729:139952118695680]: SSL state (connect): SSLv3 flush data2013.11.17 15:58:34 LOG7[23729:139952118695680]: SSL state (connect): SSLv3 read server session ticket A2013.11.17 15:58:34 LOG7[23729:139952118695680]: SSL state (connect): SSLv3 read finished A2013.11.17 15:58:34 LOG7[23729:139952118695680]: 1 items in the session cache2013.11.17 15:58:34 LOG7[23729:139952118695680]: 1 client connects (SSL_connect())2013.11.17 15:58:34 LOG7[23729:139952118695680]: 1 client connects that finished2013.11.17 15:58:34 LOG7[23729:139952118695680]: 0 client renegotiations requested2013.11.17 15:58:34 LOG7[23729:139952118695680]: 0 server connects (SSL_accept())2013.11.17 15:58:34 LOG7[23729:139952118695680]: 0 server connects that finished2013.11.17 15:58:34 LOG7[23729:139952118695680]: 0 server renegotiations requested2013.11.17 15:58:34 LOG7[23729:139952118695680]: 0 session cache hits2013.11.17 15:58:34 LOG7[23729:139952118695680]: 0 external session cache hits2013.11.17 15:58:34 LOG7[23729:139952118695680]: 0 session cache misses2013.11.17 15:58:34 LOG7[23729:139952118695680]: 0 session cache timeouts2013.11.17 15:58:34 LOG6[23729:139952118695680]: SSL connected: new session negotiated2013.11.17 15:58:34 LOG6[23729:139952118695680]: Negotiated ciphers: RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA12013.11.17 15:58:34 LOG7[23729:139952118695680]: SSL socket closed on SSL_read2013.11.17 15:58:34 LOG7[23729:139952118695680]: Socket write shutdown2013.11.17 15:58:34 LOG5[23729:139952118695680]: Connection closed: 90 bytes sent to SSL, 860 bytes sent to socket2013.11.17 15:58:34 LOG7[23729:139952118695680]: gmail-smtp finished (0 left)2013.11.17 16:01:01 LOG7[23729:139952118699968]: gmail-smtp accepted FD=13 from 127.0.0.1:561202013.11.17 16:01:01 LOG7[23729:139952118695680]: gmail-smtp started2013.11.17 16:01:01 LOG7[23729:139952118695680]: FD 13 in non-blocking mode2013.11.17 16:01:01 LOG7[23729:139952118695680]: Waiting for a libwrap process2013.11.17 16:01:01 LOG7[23729:139952118695680]: Acquired libwrap process #02013.11.17 16:01:01 LOG7[23729:139952118695680]: Releasing libwrap process #02013.11.17 16:01:01 LOG7[23729:139952118695680]: Released libwrap process #02013.11.17 16:01:01 LOG7[23729:139952118695680]: gmail-smtp permitted by libwrap from 127.0.0.1:561202013.11.17 16:01:01 LOG5[23729:139952118695680]: gmail-smtp accepted connection from 127.0.0.1:561202013.11.17 16:01:01 LOG7[23729:139952118695680]: FD 14 in non-blocking mode2013.11.17 16:01:01 LOG6[23729:139952118695680]: connect_blocking: connecting 74.125.129.109:4652013.11.17 16:01:01 LOG7[23729:139952118695680]: connect_blocking: s_poll_wait 74.125.129.109:465: waiting 10 seconds2013.11.17 16:01:01 LOG5[23729:139952118695680]: connect_blocking: connected 74.125.129.109:4652013.11.17 16:01:01 LOG5[23729:139952118695680]: gmail-smtp connected remote server from 172.31.22.161:569712013.11.17 16:01:01 LOG7[23729:139952118695680]: Remote FD=14 initialized2013.11.17 16:01:01 LOG7[23729:139952118695680]: SSL state (connect): before/connect initialization2013.11.17 16:01:01 LOG7[23729:139952118695680]: SSL state (connect): SSLv3 write client hello A2013.11.17 16:01:01 LOG7[23729:139952118695680]: SSL state (connect): SSLv3 read server hello A2013.11.17 16:01:01 LOG7[23729:139952118695680]: SSL state (connect): SSLv3 read finished A2013.11.17 16:01:01 LOG7[23729:139952118695680]: SSL state (connect): SSLv3 write change cipher spec A2013.11.17 16:01:01 LOG7[23729:139952118695680]: SSL state (connect): SSLv3 write finished A2013.11.17 16:01:01 LOG7[23729:139952118695680]: SSL state (connect): SSLv3 flush data2013.11.17 16:01:01 LOG7[23729:139952118695680]: 1 items in the session cache2013.11.17 16:01:01 LOG7[23729:139952118695680]: 2 client connects (SSL_connect())2013.11.17 16:01:01 LOG7[23729:139952118695680]: 2 client connects that finished2013.11.17 16:01:01 LOG7[23729:139952118695680]: 0 client renegotiations requested2013.11.17 16:01:01 LOG7[23729:139952118695680]: 0 server connects (SSL_accept())2013.11.17 16:01:01 LOG7[23729:139952118695680]: 0 server connects that finished2013.11.17 16:01:01 LOG7[23729:139952118695680]: 0 server renegotiations requested2013.11.17 16:01:01 LOG7[23729:139952118695680]: 1 session cache hits2013.11.17 16:01:01 LOG7[23729:139952118695680]: 0 external session cache hits2013.11.17 16:01:01 LOG7[23729:139952118695680]: 0 session cache misses2013.11.17 16:01:01 LOG7[23729:139952118695680]: 0 session cache timeouts2013.11.17 16:01:01 LOG6[23729:139952118695680]: SSL connected: previous session reused2013.11.17 16:01:02 LOG7[23729:139952118695680]: SSL socket closed on SSL_read2013.11.17 16:01:02 LOG7[23729:139952118695680]: Socket write shutdown2013.11.17 16:01:02 LOG5[23729:139952118695680]: Connection closed: 241 bytes sent to SSL, 825 bytes sent to socket2013.11.17 16:01:02 LOG7[23729:139952118695680]: gmail-smtp finished (0 left) Thanks a lot

1 0

Weird tunneling eMule's web interface
by Javier 17 Nov '13

17 Nov '13

Hi there, lets see: When I setup a server for the eMule's web interface and I access with the browser through https, the result is that the web interface never fully loads. When I setup a server for the web interface and a client connecting to that server and I access with the browser through http and with help of the client, the web interface loads without problems. Ok, at this point you think... "maybe the browser doesn't understand stunnel server at first instance for some reason... and needs the client to have a good SSL connection". So, we complicate things.... ;-) I made the following scenario because, sometimes, you can't use a client in the remote computer (where is not the web interface, if you are lost what with I'm telling). So, now we setup a server for the web interface, a client that connects to the server and a new server that connects to the client to serve to the remote browser... and... happens the same as the first example, as if it was only one server serving the web interface: it never fully loads. (I know, this scenario was quite weird :-P ). In case it was the browser I checked max connections, pipelining, etc, (allowing crazy max connection limits) but that didn't help on success :-( No matter of what web browser I use, they all do the same. They create between 7 to 15 connections with stunnel (sometimes more, others less) and nothing else. With the help of the client, all is smooth with over 150 connections. I tried too to create an html file "similar" to the web interface with the same resources (basically loads of images and therefore requests per second) and with my own web server and, in this case, there was no drama at all. The browsers connect to the stunnel server with over 190 connections in an eye blink and without of an stunnel client. At this point, I'm quite lost :-S Why doesn't load the web interface connecting directly to the stunnel server but does with the help of a client? Any ideas? Probably is the built-in web server of eMule, but it doesn't give problems when there is no stunnel in between or when using an stunnel client to connect to that stunnel server :S If you use eMule, test it and tell me if it works for you. Regards. P.S.: I hope you understood all because, even for me, has been confusing to explain.

1 0

stunnel server configuration requirement to handle CBC protection
by Simner, John 13 Nov '13

13 Nov '13

Hi, Having recently used stunnel on the phone as a server to encrypt the communication between an external client and a simple TCP server socket on the phone, one of the clients have raised the following.... Phone resets a TLS conection from client, when CBC protection is enabled on tomcat server. The phone syslog shows: Oct 28 14:26:14 10 user.crit syslog: CommsChannelExtenderRx(28881): ./src/CommsChannelExtenderRx.cpp:186 Header section invalid To prevent a SSL/TLS BEAST attack (CVE-2011-3389) Oracle Java (JSSE) has implemented a CBC protection which can be set with System Property jsse.enableCBCProtection. The default value is true. What was done: Start client and connect it with a phone. The TLS connection is established, but then the phone resets the connection, and client is not working. When I set jsse.enableCBCProtection to false at the tomcat server, the phone accepts the connection and client is working. To prevent man-in-the-middle attacks, the phone should be able to handle the fragmented TLS block when CBC protection is activated on the client tomcat server. I have been unable to find the appropriate stunnel configuration item to support this. Please could you inform me how this is handled through stunnel. Thank you for your assistance and I look forward to your responses. Thanks.. John John Simner BSc(Hons) MSc CEng. MIET Software Engineer Unify Enterprise Communications Ltd. Devices Development K Block, Technology Drive, Beeston, Nottingham, NG9 1LA Tel.: +44 (0) 19088 17378 Email: john.simner(a)unify.com <mailto:[email protected]> www.unify.co.uk<http://www.unify.co.uk/> Follow us: [Social_media_icons] <http://www.unify.com/social-media> Unify Enterprise Communications Limited. Registered Office: Brickhill Street, Willen Lake, Milton Keynes, MK15 0DJ Registered No: 5903714, England. This email contains confidential information and is for the exclusive use of the addressee. If you are not the addressee then any distribution, copying, or use of this email is prohibited. If received in error, please advise the sender and delete immediately. We accept no liability for any loss or damage suffered by any person arising from use of this email.

4 10

Patch for Start TLS for LDAP clients (RFC 2830)
by Bart Dopheide 07 Nov '13

07 Nov '13

Hi, I noticed that latest/greatest stunnel does not support the Start TLS operation for LDAP (RFC2830). Yet, I need it in my organisation as a quick workaround. After fiddling with OpenLDAP, tracing, and reading RFC 2830 a bit, I patched stunnel 4.56 and the patch has not failed me yet. But I must remark that I am no LDAP expert, nor an certified stunnel hacker. So, I will submit this patch as a first suggestion. Will you consider the feature request of implementing the Start TLS feature as described in RFC 2830? Cheers, Bart Dopheide My patch suggestion is: dopheideb@anguish:/tmp$ diff -aur stunnel-4.56 stunnel-4.56-ldap-starttls-patch diff -aur stunnel-4.56/src/protocol.c stunnel-4.56-ldap-starttls-patch/src/protocol.c --- stunnel-4.56/src/protocol.c 2013-03-13 14:41:16.000000000 +0100 +++ stunnel-4.56-ldap-starttls-patch/src/protocol.c 2013-11-05 11:19:10.388365359 +0100 @@ -53,6 +53,7 @@ static void imap_client(CLI *); static void imap_server(CLI *); static void nntp_client(CLI *); +static void openldap_client(CLI *); static void connect_server(CLI *); static void connect_client(CLI *); @@ -82,6 +83,7 @@ {"pop3", {{PROTOCOL_PRE_SSL, pop3_server}, {PROTOCOL_PRE_SSL, pop3_client}}}, {"imap", {{PROTOCOL_PRE_SSL, imap_server}, {PROTOCOL_PRE_SSL, imap_client}}}, {"nntp", {{PROTOCOL_NONE, NULL}, {PROTOCOL_PRE_SSL, nntp_client}}}, + {"openldap",{{PROTOCOL_NONE, NULL}, {PROTOCOL_PRE_SSL, openldap_client}}}, {"connect", {{PROTOCOL_PRE_CONNECT, connect_server}, {PROTOCOL_PRE_SSL, connect_client}}}, {NULL, {{PROTOCOL_NONE, NULL}, {PROTOCOL_NONE, NULL}}} }; @@ -513,6 +515,88 @@ str_free(line); } +/**************************************** LDAP, RFC 2830 */ + +u8 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") */ +}; +static void openldap_client(CLI *c) { + u8 buffer[1]; + u8 ldap_response[256]; + + s_log(LOG_DEBUG, "Requesting LDAP Start TLS"); + write_blocking(c, c->remote_fd.fd, ldap_startssl_message, ldap_startssl_message[1] + 2); + + read_blocking(c, c->remote_fd.fd, buffer, 1); + if(buffer[0] != 0x30) { + s_log(LOG_ERR, "start tag is not UNIVERSAL SEQUENCE"); + longjmp(c->err, 1); + } + + s_log(LOG_DEBUG, "Reading LDAP message size (1 byte)."); + read_blocking(c, c->remote_fd.fd, buffer, 1); + + s_log(LOG_DEBUG, "Reading LDAP message (%u byte(s))", buffer[0]); + read_blocking(c, c->remote_fd.fd, ldap_response, buffer[0]); + + if(ldap_response[0] != 0x02) { + s_log(LOG_ERR, "LDAP response does not start with type messageID"); + longjmp(c->err, 1); + } + if(ldap_response[1] != 0x01) { + s_log(LOG_ERR, "This is not an extendedResp(1)"); + longjmp(c->err, 1); + } + if(ldap_response[2] != 0x01) { + s_log(LOG_ERR, "Non-matching messageID"); + longjmp(c->err, 1); + } + if(ldap_response[3] != 0x78) { + s_log(LOG_ERR, "This is not a protocolOp for APPLICATION ExtendedResponse"); + longjmp(c->err, 1); + } + if(ldap_response[4] != 0x07) { + s_log(LOG_ERR, "Expected 0x07 indicating extendedResp is 7 bytes long"); + longjmp(c->err, 1); + } + if(ldap_response[5] != 0x0a) { + s_log(LOG_ERR, "This is not an extendedResp"); + longjmp(c->err, 1); + } + if(ldap_response[6] != 0x01) { + s_log(LOG_ERR, "This is not an extendedResp"); + longjmp(c->err, 1); + } + if(ldap_response[7] != 0x00) { + s_log(LOG_ERR, "This is not resultCode success"); + longjmp(c->err, 1); + } +} + /**************************************** connect */ static void connect_server(CLI *c) { dopheideb@anguish:/tmp$

3 2