Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Enabling Logging in OpenSSL
7,220 views
Skip to first unread message
Mithun Kumar
Sep 10, 2012, 1:56:24 AM9/10/12
to
Hello All,
I have a challenge befor me where i have to debug a SSL handshake failure. Client has OpenSSL libraries and Server is Microsoft SQL Server. I cant sniff the packets using WireShark nor can i enable server logs. All i can do i enable client logging. Any suggestions how to enable OpenSSL logging?
I have enabled API calls "err_error_string_n" and "err_peek_error_line_data" to get the error information. Any suggestions?
-Mithun
I have a challenge befor me where i have to debug a SSL handshake failure. Client has OpenSSL libraries and Server is Microsoft SQL Server. I cant sniff the packets using WireShark nor can i enable server logs. All i can do i enable client logging. Any suggestions how to enable OpenSSL logging?
I have enabled API calls "err_error_string_n" and "err_peek_error_line_data" to get the error information. Any suggestions?
-Mithun
Dave Thompson
Sep 10, 2012, 4:22:41 AM9/10/12
to
>From: owner-ope...@openssl.org On Behalf Of Mithun Kumar
>Sent: Monday, 10 September, 2012 01:56
Answering -users only, this isn't a -dev question.
>I have a challenge befor me where i have to debug a SSL handshake
>failure. Client has OpenSSL libraries and Server is Microsoft
>SQL Server. I cant sniff the packets using WireShark nor can i
>enable server logs. All i can do i enable client logging. Any
>suggestions how to enable OpenSSL logging?
1. Are you not permitted to use WireShark, or just having
difficulty doing so? If the latter, maybe we can help.
WireShark's decoding is much easier than doing it by hand.
2. If it's a handshake failure, can you use commandline
s_client? That has logging builtin, use -msg and/or -debug .
3. Look at the code for s_client (and s_cb.c) and do in your
app what it does: write a message callback and attach it
to SSL and/or a BIO callback and attach it to the line BIO.
You can probably omit some of the decoding, but
you still need probably 20-50 lines or so.
>I have enabled API calls "err_error_string_n" and
>"err_peek_error_line_data" to get the error information. Any suggestions?
By "enabled" you mean you call them after an error occurs?
These routines begin with ERR_ (case matters in C). Many
errors have more than one entry in the error queue; to see
all of them you need to use _get_ not _peek_.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openss...@openssl.org
Automated List Manager majo...@openssl.org
>Sent: Monday, 10 September, 2012 01:56
Answering -users only, this isn't a -dev question.
>I have a challenge befor me where i have to debug a SSL handshake
>failure. Client has OpenSSL libraries and Server is Microsoft
>SQL Server. I cant sniff the packets using WireShark nor can i
>enable server logs. All i can do i enable client logging. Any
>suggestions how to enable OpenSSL logging?
difficulty doing so? If the latter, maybe we can help.
WireShark's decoding is much easier than doing it by hand.
2. If it's a handshake failure, can you use commandline
s_client? That has logging builtin, use -msg and/or -debug .
3. Look at the code for s_client (and s_cb.c) and do in your
app what it does: write a message callback and attach it
to SSL and/or a BIO callback and attach it to the line BIO.
You can probably omit some of the decoding, but
you still need probably 20-50 lines or so.
>I have enabled API calls "err_error_string_n" and
>"err_peek_error_line_data" to get the error information. Any suggestions?
These routines begin with ERR_ (case matters in C). Many
errors have more than one entry in the error queue; to see
all of them you need to use _get_ not _peek_.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openss...@openssl.org
Automated List Manager majo...@openssl.org
Mithun Kumar
Sep 10, 2012, 8:17:17 AM9/10/12
to
Hello Dave,
Please find my reply inline
Mithun>>Last time i used i got the below
soniclx24(misingh): openssl s_client -connect NC-WIN2008X64:1433 -state -debug -msg -ssl3
CONNECTED(00000003)
SSL_connect:before/connect initialization
write to 08A018A8 [08A0B660] (100 bytes => 100 (0x64))
0000 - 16 03 00 00 5f 01 00 00-5b 03 00 50 3f fb 58 60 ...._...[..P?.X`
0010 - 71 d6 9f 3c a6 fb 60 79-8a 31 fe 39 68 46 0e a0 q..<..`y.1.9hF..
0020 - 3f 0d c8 08 d9 62 da c6-17 fc 8d 00 00 34 00 39 ?....b.......4.9
0030 - 00 38 00 35 00 16 00 13-00 0a 00 33 00 32 00 2f .8.5.......3.2./
0040 - 00 66 00 05 00 04 00 63-00 62 00 61 00 15 00 12 .f.....c.b.a....
0050 - 00 09 00 65 00 64 00 60-00 14 00 11 00 08 00 06 ...e.d.`........
0060 - 00 03 01 ...
0064 - <SPACES/NULS>
>>> SSL 3.0 Handshake [length 005f], ClientHello
01 00 00 5b 03 00 50 3f fb 58 60 71 d6 9f 3c a6
fb 60 79 8a 31 fe 39 68 46 0e a0 3f 0d c8 08 d9
62 da c6 17 fc 8d 00 00 34 00 39 00 38 00 35 00
16 00 13 00 0a 00 33 00 32 00 2f 00 66 00 05 00
04 00 63 00 62 00 61 00 15 00 12 00 09 00 65 00
64 00 60 00 14 00 11 00 08 00 06 00 03 01 00
SSL_connect:SSLv3 write client hello A
read from 08A018A8 [08A06E50] (5 bytes => 0 (0x0))
SSL_connect:failed in SSLv3 read server hello A
12542:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:529:
I see your reply
Read count 0 nominally means the server closed the TCP connection, neither continuing the handshake (with ServerHello)nor cleanly aborting (with alert). A compliant server shouldn't do this, but some do, especially if it judges you shouldn't be allowed to connect e.g. blacklisted IPaddr, too many attempts too fast, etc. Ask the server operator(s) why it didn't/doesn't like you.
Alternatively, there is a remote possibility some middlebox in your network path such as a firewall is doing the close. However middleboxes usually do this earlier: on the TCP connection (SYN) not during SSL handshake, which is "just" data to the TCP/IP level.
Any work around that you suggest ?
Mithun>> I am using API ERR_peek_error_line_data()
Please find my reply inline
On Mon, Sep 10, 2012 at 1:52 PM, Dave Thompson <dtho...@prinpay.com> wrote:
>From: owner-ope...@openssl.org On Behalf Of Mithun Kumar
>Sent: Monday, 10 September, 2012 01:56
Answering -users only, this isn't a -dev question.
1. Are you not permitted to use WireShark, or just having
>I have a challenge befor me where i have to debug a SSL handshake
>failure. Client has OpenSSL libraries and Server is Microsoft
>SQL Server. I cant sniff the packets using WireShark nor can i
>enable server logs. All i can do i enable client logging. Any
>suggestions how to enable OpenSSL logging?
difficulty doing so? If the latter, maybe we can help.
WireShark's decoding is much easier than doing it by hand.
Mithun>> Yes i am not allowed to use WireShark.
2. If it's a handshake failure, can you use commandline
s_client? That has logging builtin, use -msg and/or -debug .
Mithun>>Last time i used i got the below
soniclx24(misingh): openssl s_client -connect NC-WIN2008X64:1433 -state -debug -msg -ssl3
CONNECTED(00000003)
SSL_connect:before/connect initialization
write to 08A018A8 [08A0B660] (100 bytes => 100 (0x64))
0000 - 16 03 00 00 5f 01 00 00-5b 03 00 50 3f fb 58 60 ...._...[..P?.X`
0010 - 71 d6 9f 3c a6 fb 60 79-8a 31 fe 39 68 46 0e a0 q..<..`y.1.9hF..
0020 - 3f 0d c8 08 d9 62 da c6-17 fc 8d 00 00 34 00 39 ?....b.......4.9
0030 - 00 38 00 35 00 16 00 13-00 0a 00 33 00 32 00 2f .8.5.......3.2./
0040 - 00 66 00 05 00 04 00 63-00 62 00 61 00 15 00 12 .f.....c.b.a....
0050 - 00 09 00 65 00 64 00 60-00 14 00 11 00 08 00 06 ...e.d.`........
0060 - 00 03 01 ...
0064 - <SPACES/NULS>
>>> SSL 3.0 Handshake [length 005f], ClientHello
01 00 00 5b 03 00 50 3f fb 58 60 71 d6 9f 3c a6
fb 60 79 8a 31 fe 39 68 46 0e a0 3f 0d c8 08 d9
62 da c6 17 fc 8d 00 00 34 00 39 00 38 00 35 00
16 00 13 00 0a 00 33 00 32 00 2f 00 66 00 05 00
04 00 63 00 62 00 61 00 15 00 12 00 09 00 65 00
64 00 60 00 14 00 11 00 08 00 06 00 03 01 00
SSL_connect:SSLv3 write client hello A
read from 08A018A8 [08A06E50] (5 bytes => 0 (0x0))
SSL_connect:failed in SSLv3 read server hello A
12542:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:529:
I see your reply
Read count 0 nominally means the server closed the TCP connection, neither continuing the handshake (with ServerHello)nor cleanly aborting (with alert). A compliant server shouldn't do this, but some do, especially if it judges you shouldn't be allowed to connect e.g. blacklisted IPaddr, too many attempts too fast, etc. Ask the server operator(s) why it didn't/doesn't like you.
Alternatively, there is a remote possibility some middlebox in your network path such as a firewall is doing the close. However middleboxes usually do this earlier: on the TCP connection (SYN) not during SSL handshake, which is "just" data to the TCP/IP level.
Any work around that you suggest ?
3. Look at the code for s_client (and s_cb.c) and do in your
app what it does: write a message callback and attach it
to SSL and/or a BIO callback and attach it to the line BIO.
You can probably omit some of the decoding, but
you still need probably 20-50 lines or so.
By "enabled" you mean you call them after an error occurs?
>I have enabled API calls "err_error_string_n" and
>"err_peek_error_line_data" to get the error information. Any suggestions?
These routines begin with ERR_ (case matters in C). Many
errors have more than one entry in the error queue; to see
all of them you need to use _get_ not _peek_.
Mithun>> I am using API ERR_peek_error_line_data()
Dave Thompson
Sep 10, 2012, 10:38:01 PM9/10/12
to
>From: owner-ope...@openssl.org On Behalf Of Mithun Kumar
>Sent: Monday, 10 September, 2012 08:17
> 2. If it's a handshake failure, can you use commandline
> s_client? That has logging builtin, use -msg and/or -debug .
>Mithun>>Last time i used i got the below
>...openssl s_client -connect NC-WIN2008X64:1433 -state -debug -msg -ssl3
> s_client? That has logging builtin, use -msg and/or -debug .
>Mithun>>Last time i used i got the below
<snip>
>SSL_connect:SSLv3 write client hello A
>read from 08A018A8 [08A06E50] (5 bytes => 0 (0x0))
>SSL_connect:failed in SSLv3 read server hello A
>12542:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake
failure:s3_pkt.c:529:
>I see your reply
> Read count 0 nominally means the server closed the TCP connection,
> neither continuing the handshake (with ServerHello)nor cleanly aborting
> (with alert). A compliant server shouldn't do this, but some do,
especially
> if it judges you shouldn't be allowed to connect e.g. blacklisted IPaddr,
> too many attempts too fast, etc. Ask the server operator(s) why it
> didn't/doesn't like you.
> Alternatively, there is a remote possibility some middlebox in your
> network path such as a firewall is doing the close. However middleboxes
> usually do this earlier: on the TCP connection (SYN) not during SSL
> handshake, which is "just" data to the TCP/IP level.
>Any work around that you suggest ?
I didn't notice before, but 1433 on Windows is usually SQLServer.
>read from 08A018A8 [08A06E50] (5 bytes => 0 (0x0))
>SSL_connect:failed in SSLv3 read server hello A
>12542:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake
failure:s3_pkt.c:529:
>I see your reply
> Read count 0 nominally means the server closed the TCP connection,
> neither continuing the handshake (with ServerHello)nor cleanly aborting
> (with alert). A compliant server shouldn't do this, but some do,
especially
> if it judges you shouldn't be allowed to connect e.g. blacklisted IPaddr,
> too many attempts too fast, etc. Ask the server operator(s) why it
> didn't/doesn't like you.
> Alternatively, there is a remote possibility some middlebox in your
> network path such as a firewall is doing the close. However middleboxes
> usually do this earlier: on the TCP connection (SYN) not during SSL
> handshake, which is "just" data to the TCP/IP level.
>Any work around that you suggest ?
If so, SQLServer doesn't start in SSL; it starts in a SQLServer protocol
(TDS) and optionally switches to SSL. If you connect to 1433 and just start
an SSL handshake, SQLServer will consider this a violation of TDS protocol.
This falls under the case in my prior reply "make sure the server is doing
SSL". And in fact on my elderly SQLServer2005 Express, connecting to 1433
and starting -ssl3 handshake does exactly as you report, with an event
logged:
source=MSSQLSERVER eventid=17836
Length specified in network packet payload did not match number of bytes
read;
the connection has been closed. Please contact the vendor of the client
library.
[CLIENT: 127.0.0.1]
whereas a (default) ssl2 clienthello hangs (at least 1minute).
Looking briefly at a trace of a clear TDS connection, it appears that
bytes 2 and 3 are (bigendian inclusive) length, and in ssl3 clienthello
these are 00 00 which is clearly invalid, whereas in ssl2 clienthello
they are 01 00 which is longer than the message actually sent, thus
the server is likely waiting for the rest of the supposed TDS message.
In this case, you must implement the TDS protocol, or at least the part
of it that starts SSL. (And once you get SSL, you still need to implement
the TDS protocol if you want to use the connection for anything.)
I haven't found protocol doc or sourcecode available from Microsoft
(which doesn't prove it isn't there somewhere I don't know about).
freetds.sourceforge.net claims to be an opensource driver
implementation, using either gnutls or openssl; I haven't tried it,
but it might work for you, or looking at the source might help.
jtds.sourceforge.net is a Java port of freetds that I do use okay,
and Java's SSL implementation (JSSE) has the feature that (fairly
verbose) logging can be turned on by a sysprop without code change:
http://docs.oracle.com/javase/6/docs/technotes/guides/security/jsse/JSSERefG
uide.html#Debug
If 1433 is not SQLServer, I'm back to: find out what it dislikes.
Mithun Kumar
Sep 11, 2012, 2:10:09 AM9/11/12
to
Thanks Dave, Please find my reply inline.
Mithun>>I am trying to connect to SQLServer which by default starts in TDS. you said " And in fact on my elderly SQLServer2005 Express, connecting to 1433 and starting -ssl3 handshake does exactly as you report, with an event logged:
source=MSSQLSERVER eventid=17836"
Did you get the events logged in SQLServer Log's? Can you please elaborate so that i can confirm what i am seeing?
JSSE tracing indeed gives in detail log on the handshake , Unfortunately i am not sure how to enable the same on SQLServer !!!
source=MSSQLSERVER eventid=17836"
Did you get the events logged in SQLServer Log's? Can you please elaborate so that i can confirm what i am seeing?
JSSE tracing indeed gives in detail log on the handshake , Unfortunately i am not sure how to enable the same on SQLServer !!!
Dave Thompson
Sep 11, 2012, 10:55:07 PM9/11/12
to
>From: owner-ope...@openssl.org On Behalf Of Mithun Kumar
>Sent: Tuesday, 11 September, 2012 02:10
<snip>
> I didn't notice before, but 1433 on Windows is usually SQLServer.
> If so, SQLServer doesn't start in SSL; it starts in a SQLServer
protocol
> (TDS) and optionally switches to SSL. If you connect to 1433 and
just start
> an SSL handshake, SQLServer will consider this a violation of TDS
protocol.
> <snip> And in fact on my elderly SQLServer2005 Express, connecting
> If so, SQLServer doesn't start in SSL; it starts in a SQLServer
protocol
> (TDS) and optionally switches to SSL. If you connect to 1433 and
just start
> an SSL handshake, SQLServer will consider this a violation of TDS
protocol.
to 1433
> and starting -ssl3 handshake does exactly as you report, with an
event logged:
> source=MSSQLSERVER eventid=17836
> Length specified in network packet payload did not match number of
bytes read;
> the connection has been closed. Please contact the vendor of the
client library.
> [CLIENT: 127.0.0.1]
> whereas a (default) ssl2 clienthello hangs (at least 1minute).
<snip>
> and starting -ssl3 handshake does exactly as you report, with an
event logged:
> source=MSSQLSERVER eventid=17836
> Length specified in network packet payload did not match number of
bytes read;
> the connection has been closed. Please contact the vendor of the
client library.
> [CLIENT: 127.0.0.1]
> whereas a (default) ssl2 clienthello hangs (at least 1minute).
> In this case, you must implement the TDS protocol, or at least the
part
> jtds.sourceforge.net is a Java port of freetds that I do use okay,
> and Java's SSL implementation (JSSE) has the feature that (fairly
> verbose) logging can be turned on by a sysprop <snip>
> and Java's SSL implementation (JSSE) has the feature that (fairly
>Mithun>>I am trying to connect to SQLServer which by default starts in TDS.
>you said " And in fact on my elderly SQLServer2005 Express, connecting to
1433
>and starting -ssl3 handshake does exactly as you report, with an event
logged:
>source=MSSQLSERVER eventid=17836"
>Did you get the events logged in SQLServer Log's? Can you please elaborate
>so that i can confirm what i am seeing?
quicker for me to use, but it is also in the SQLServer ERRORLOG.
There was exactly one event for the one ssl3 handshake attempt.
>JSSE tracing indeed gives in detail log on the handshake , Unfortunately
>i am not sure how to enable the same on SQLServer !!!
But do you need to? If there is no network problem in between,
the messages sent and received by the client, here jtds, are the
same as the messages received and sent by the server.
Mithun Kumar
Sep 14, 2012, 8:52:47 PM9/14/12
to
Hello Dave,
On the issue i am working currently after i connect to a SQL Server, Client hello is sent successfully but I am not getting server hello and READ() below returns as highlighted. Looks like server is closing the connection after receiving a client hello. On the screen i see Socket Closed exception.
s3_both.c:401
if (s->state == st1) /* s->init_num < 4 */
{
int skip_message;
do
{
while (s->init_num < 4)
{
i=s->method->ssl_read_bytes(s,SSL3_RT_HANDSHAKE,
&p[s->init_num],4 - s->init_num, 0);
if (i <= 0)
{
s->rwstate=SSL_READING;
*ok = 0;
return i; //returns here
}
s->init_num+=i;
}
Any troubleshooting tips to debug the Issue as SQL Server starts with TDS and not SSL? I am blocked on this issue. I have already tried s_client and discussion related to it is in our previous mail chain. How to know if any firewall or middle box are not playing spoil sport?
Any inputs will be of great help.
-mithun
On the issue i am working currently after i connect to a SQL Server, Client hello is sent successfully but I am not getting server hello and READ() below returns as highlighted. Looks like server is closing the connection after receiving a client hello. On the screen i see Socket Closed exception.
s3_both.c:401
if (s->state == st1) /* s->init_num < 4 */
{
int skip_message;
do
{
while (s->init_num < 4)
{
i=s->method->ssl_read_bytes(s,SSL3_RT_HANDSHAKE,
&p[s->init_num],4 - s->init_num, 0);
if (i <= 0)
{
s->rwstate=SSL_READING;
*ok = 0;
return i; //returns here
}
s->init_num+=i;
}
Any troubleshooting tips to debug the Issue as SQL Server starts with TDS and not SSL? I am blocked on this issue. I have already tried s_client and discussion related to it is in our previous mail chain. How to know if any firewall or middle box are not playing spoil sport?
Any inputs will be of great help.
-mithun
On Wed, Sep 12, 2012 at 8:25 AM, Dave Thompson <dtho...@prinpay.com> wrote:
>From: owner-ope...@openssl.org On Behalf Of Mithun Kumar>Sent: Tuesday, 11 September, 2012 02:10
<snip>
> I didn't notice before, but 1433 on Windows is usually SQLServer.
> If so, SQLServer doesn't start in SSL; it starts in a SQLServer
protocol
> (TDS) and optionally switches to SSL. If you connect to 1433 and
just start
> an SSL handshake, SQLSrver will consider this a violation of TDS
protocol.
Dave Thompson
Sep 17, 2012, 2:45:06 PM9/17/12
to
>From: owner-ope...@openssl.org On Behalf Of Mithun Kumar
>Sent: Friday, 14 September, 2012 20:53
>On the issue i am working currently after i connect to a SQL Server,
>Client hello is sent successfully but I am not getting server hello
>and READ() below returns as highlighted. Looks like server is closing
>the connection after receiving a client hello. On the screen i see
>Socket Closed exception.
If you connect to SQLServer and immediately start an SSL handshake,
the server considers it illegal and closes. So, don't do that.
If you *are* doing the TDS needed to start SSL but it isn't working
right, there should be some error indication *in TDS* (but I don't
know what) and you shouldn't even attempt the SSL handshake.
Mithun Kumar
Sep 18, 2012, 12:36:49 AM9/18/12
to
Hello Dave,
Below is what i see in Server Logs
"Encryption is required to connect to this server but the client library does not support encryption; the connection has been closed. Please upgrade your client library. Error: 17835, Severity: 20, State: 1"
Do you have any pointers? Have you encountered any time before such errors in forum?
-mithun
Below is what i see in Server Logs
"Encryption is required to connect to this server but the client library does not support encryption; the connection has been closed. Please upgrade your client library. Error: 17835, Severity: 20, State: 1"
Do you have any pointers? Have you encountered any time before such errors in forum?
-mithun
Dave Thompson
Sep 18, 2012, 6:31:39 PM9/18/12
to
>From: owner-ope...@openssl.org On Behalf Of Mithun Kumar
>Sent: Tuesday, 18 September, 2012 00:37
>Hello Dave,
>Below is what i see in Server Logs
>"Encryption is required to connect to this server but the
>client library does not support encryption; the connection
>has been closed. Please upgrade your client library.
>Error: 17835, Severity: 20, State: 1"
>Do you have any pointers? Have you encountered any time before
>such errors in forum?
The first several google hits for SQL server error 17835
strongly suggest that the error might be that the client
"library" (aka driver) isn't *configured* correctly, not
that it doesn't actually support encryption. I would try
to check that first. If you're using one of the several
Microsoft "only and forever solution"s, you'll have to find
the correct instructions for it, or someone who knows it.
I can't help you there (and no one else has chimed in).
If the problem is truly that the client doesn't support it --
and it appears your client would have to be older than about
2005 for that to be the case -- then you need a better client.
If MS, I would stick with it and upgrade -- upgrading existing
product "in place" is one thing MS usually does pretty well.
If you're using some third-party product see if it can be upgraded,
and if not change to something else, like MS -- or ask to get the
encryption requirement relaxed, although depending on the data
on this server that may not be possible in the current world of
increasing attacks and liability or penalty for breaches.
If for some reason you can't use an MS driver and can't find or
use a third-party driver, and are left to implement it yourself,
you will have to implement TDS *and* SSL. You can use OpenSSL for
the SSL part, but I doubt anyone here can help you for TDS.
John A. Wallace
Nov 1, 2012, 12:00:16 PM11/1/12
to
Not sure if this is the right place to ask, but I will give it a try because
it seems likely that someone here can point me in the right direction if
need be. I am not a programmer.
I have an application that can make http connections but not https. The
connections are made from a Windows command line interface, not a browser. I
would like to enable it to make https connections too without having to
reinvent the wheel. If there is some way to connect it to an intermediary
proxy program that does have built-in support for the https protocol, that
would be swell. Is such a thing possible or is there another solution I
don't see? Thanks.
John
it seems likely that someone here can point me in the right direction if
need be. I am not a programmer.
I have an application that can make http connections but not https. The
connections are made from a Windows command line interface, not a browser. I
would like to enable it to make https connections too without having to
reinvent the wheel. If there is some way to connect it to an intermediary
proxy program that does have built-in support for the https protocol, that
would be swell. Is such a thing possible or is there another solution I
don't see? Thanks.
John
Jakob Bohm
Nov 1, 2012, 1:24:57 PM11/1/12
to
(Note you really should have started a new thread, not replied to an old
one).
On 11/1/2012 5:00 PM, John A. Wallace wrote:
> Not sure if this is the right place to ask, but I will give it a try because
> it seems likely that someone here can point me in the right direction if
> need be. I am not a programmer.
>
> I have an application that can make http connections but not https. The
> connections are made from a Windows command line interface, not a browser. I
> would like to enable it to make https connections too without having to
> reinvent the wheel. If there is some way to connect it to an intermediary
> proxy program that does have built-in support for the https protocol, that
> would be swell. Is such a thing possible or is there another solution I
> don't see? Thanks.
>
>
If you don't want to link the SSL code into you application, look up
"stunnel", which is a free program (for Windows too) which does almost
exactly what you ask for.
If you would rather link the code into your application, you are in
the right place, this is exactly what OpenSSL was originally created
for. Link your application to the latest version of OpenSSL and
follow the tutorials elsewhere for how to call it in a https client
(It is mostly about passing all your socket send/recv calls through
OpenSSL functions, plus some slightly tricky code to call when doing
connect() and socketclose()).
If you have questions about any of the function calls needed, post on
this mailing list.
P.S.
If anyone could point the OP (and others as this seems a FAQ) to a good
example of adding OpenSSL to existing socket code with current best
practices, please post it as a reply in this thread.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com
Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
one).
On 11/1/2012 5:00 PM, John A. Wallace wrote:
> Not sure if this is the right place to ask, but I will give it a try because
> it seems likely that someone here can point me in the right direction if
> need be. I am not a programmer.
>
> I have an application that can make http connections but not https. The
> connections are made from a Windows command line interface, not a browser. I
> would like to enable it to make https connections too without having to
> reinvent the wheel. If there is some way to connect it to an intermediary
> proxy program that does have built-in support for the https protocol, that
> would be swell. Is such a thing possible or is there another solution I
> don't see? Thanks.
>
>
"stunnel", which is a free program (for Windows too) which does almost
exactly what you ask for.
If you would rather link the code into your application, you are in
the right place, this is exactly what OpenSSL was originally created
for. Link your application to the latest version of OpenSSL and
follow the tutorials elsewhere for how to call it in a https client
(It is mostly about passing all your socket send/recv calls through
OpenSSL functions, plus some slightly tricky code to call when doing
connect() and socketclose()).
If you have questions about any of the function calls needed, post on
this mailing list.
P.S.
If anyone could point the OP (and others as this seems a FAQ) to a good
example of adding OpenSSL to existing socket code with current best
practices, please post it as a reply in this thread.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com
Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
John A. Wallace
Nov 2, 2012, 10:06:30 AM11/2/12
to
this program anew from source in a Linux environment? If so, what tools
would be needed to do something like that and where can I find a well-stated
"introduction" to this procedure in general? I would like to at least take a
look at it to see what is entailed. Thanks.
>
> P.S.
>
> If anyone could point the OP (and others as this seems a FAQ) to a good
> example of adding OpenSSL to existing socket code with current best
> practices, please post it as a reply in this thread.
>
Jakob Bohm
Nov 2, 2012, 11:18:43 AM11/2/12
to
If you don't know how to rebuild your application on your chosen OS,
then you should probably not even try to do this kind of programming,
I was assuming you already had those skills and had probably written
the application yourself.
Go with stunnel then, it doesn't require you to know the inner
workings of the application and how to modify its code.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com
Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
0 new messages