Watch, Follow, &
Connect with Us

For forums, blogs and more please visit our
Developer Tools Community.


Welcome, Guest
Guest Settings
Help

Thread: SSL via already running TCP/IP Connection


This question is answered.


Permlink Replies: 8 - Last Post: Apr 16, 2015 10:35 AM Last Post By: Remy Lebeau (Te...
Marcel Uhlich

Posts: 5
Registered: 9/29/07
SSL via already running TCP/IP Connection  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 26, 2015 12:29 AM
Hi Everyone,

i am writing a connection Tool for a third party device that is accessed via SSL. The exact setup is:

1. Open TCP/IP connection to the device (PC is TCP/IP client)
2. Device initiates SSL handshake (PC is SSL Server, Device is SSL client)
3. PC Accepts SSL handshake
4. Device verifies PC SSL Server
5. Connection established [running commands]

i have tried to get this done with Indy, but it seems that the Servercomponents actually cannot initiate TCP/IP (just listen/accept). I have found
third party components (Overbyte that is) where i was able to implement the above behaviour but those components require
old OpenSSL Versions that i do not wish to use.

Besides writing my own SSL Handshake procedure, is there a way with default Delphi (or Indy) to get this done? I am using Delphi XE5 for
the record.

i appreciate any insight on that

greetings!
Angus Robertson

Posts: 205
Registered: 3/17/00
Re: SSL via already running TCP/IP Connection
Correct
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 26, 2015 7:03 AM   in response to: Marcel Uhlich in response to: Marcel Uhlich
I have found third party components (Overbyte that
is) where i was able to implement the above behaviour but those
components require old OpenSSL Versions that i do not wish to use.

ICS v8 supports OpenSSL 1.0.2a which was released one week ago, there is
nothing newer, you can get v8 and the OpenSSL DLLs from:

http://wiki.overbyte.be/wiki/index.php/ICS_Download

Angus
Marcel Uhlich

Posts: 5
Registered: 9/29/07
Re: SSL via already running TCP/IP Connection  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 26, 2015 8:24 AM   in response to: Angus Robertson in response to: Angus Robertson
Hi Angus,

strange how i could miss that. I was using that version from October 2013 and thought that was the latest. Thank you very much for that link

greetings!
Remy Lebeau (Te...


Posts: 9,447
Registered: 12/23/01
Re: SSL via already running TCP/IP Connection
Helpful
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 26, 2015 12:23 PM   in response to: Marcel Uhlich in response to: Marcel Uhlich
Marcel wrote:

i have tried to get this done with Indy, but it seems that the
Servercomponents actually cannot initiate TCP/IP (just listen/accept).

You are thinking about this the wrong way. You would not use a server component
in this scenario, you need a client component that handles SSL in a server
mode.

Use TIdTCPClient (or descendant) with a TIdSSLIOHandlerSocketOpenSSL assigned
to its IOHandler property. Set the IOHandler's SSLOptions.Mode property
to sslmServer, and set its PassThrough property to false before before calling
TIdTCPClient.Connect(). That way, the SSL handshake will be accepted immediately
when the TCP/IP connection is established, before Connect() exits. If the
handshake fails, Connect() will close the connection automatically before
raising the exception into your code.

--
Remy Lebeau (TeamB)
Marcel Uhlich

Posts: 5
Registered: 9/29/07
Re: SSL via already running TCP/IP Connection  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 30, 2015 5:04 AM   in response to: Remy Lebeau (Te... in response to: Remy Lebeau (Te...
Hi Remy,

i was able to do as you recommended but i needed to set the "IsPeer" property of the ioHandler to true additionally. After that, the SSL connection was established. Thanks for your help

greetings!

Remy Lebeau (TeamB) wrote:
Marcel wrote:

i have tried to get this done with Indy, but it seems that the
Servercomponents actually cannot initiate TCP/IP (just listen/accept).

You are thinking about this the wrong way. You would not use a server component
in this scenario, you need a client component that handles SSL in a server
mode.

Use TIdTCPClient (or descendant) with a TIdSSLIOHandlerSocketOpenSSL assigned
to its IOHandler property. Set the IOHandler's SSLOptions.Mode property
to sslmServer, and set its PassThrough property to false before before calling
TIdTCPClient.Connect(). That way, the SSL handshake will be accepted immediately
when the TCP/IP connection is established, before Connect() exits. If the
handshake fails, Connect() will close the connection automatically before
raising the exception into your code.

--
Remy Lebeau (TeamB)
Remy Lebeau (Te...


Posts: 9,447
Registered: 12/23/01
Re: SSL via already running TCP/IP Connection
Helpful
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 30, 2015 11:00 AM   in response to: Marcel Uhlich in response to: Marcel Uhlich
Marcel wrote:

i was able to do as you recommended but i needed to set
the "IsPeer" property of the ioHandler to true additionally.

Yes, good catch. The IOHandler needs that in order to call SSL_accept()
instead of ssl_connect().

However, you do need to be careful with setting IsPeer manually. IsPeer
is primarily intended to be True only on a server-side (TIdTCPServer) IOHandler,
not a client-side (TIdTCPClient) IOHandler. There are some internal resources
that are not released when IsPeer is True because they are owned by something
other than the IOHandler. On the other hand, the more I think of it, it
might actually be a bug that the IOHandler is calling SSL_accept() vs SSL_connect()
based on IsPeer rather than SSLOptions.Mode, at least for sslmClient and
sslmServer (I suppose sslmBoth would have to still rely on IsPeer).

So, to avoid any leaks on a client-side IOHandler, you might need to set
PassThrough to True initially and leave IsPeer as False, then establish the
underlying TCP connection, then set IsPeer to True before setting PassThrough
to False and reset IsPeer back to False afterwards. Not sure if that would
work, I have never used an SSLIOHandler in this manner before.

I'm very curious why the device, being a TCP server, is initiating the handshake
as an SSL client instead of acting as an SSL server like most TCP servers
do. Do you know why the device is backwards like that?

--
Remy Lebeau (TeamB)
Marcel Uhlich

Posts: 5
Registered: 9/29/07
Re: SSL via already running TCP/IP Connection  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Apr 2, 2015 4:58 AM   in response to: Remy Lebeau (Te... in response to: Remy Lebeau (Te...
Hi Remy,

i will try what you have recommended and give the results here, but for now: The hardware company that is building the device only had access to a SSL Client hardware component. Therefore we decided to set up the PC as SSL Server. The device itself is some kind of passive data storage and the PC Software shall access the data actively. Therefore the device listens for incoming connection attempts and thus is the TCP Server.

Remy Lebeau (TeamB) wrote:
Marcel wrote:

i was able to do as you recommended but i needed to set
the "IsPeer" property of the ioHandler to true additionally.

Yes, good catch. The IOHandler needs that in order to call SSL_accept()
instead of ssl_connect().

However, you do need to be careful with setting IsPeer manually. IsPeer
is primarily intended to be True only on a server-side (TIdTCPServer) IOHandler,
not a client-side (TIdTCPClient) IOHandler. There are some internal resources
that are not released when IsPeer is True because they are owned by something
other than the IOHandler. On the other hand, the more I think of it, it
might actually be a bug that the IOHandler is calling SSL_accept() vs SSL_connect()
based on IsPeer rather than SSLOptions.Mode, at least for sslmClient and
sslmServer (I suppose sslmBoth would have to still rely on IsPeer).

So, to avoid any leaks on a client-side IOHandler, you might need to set
PassThrough to True initially and leave IsPeer as False, then establish the
underlying TCP connection, then set IsPeer to True before setting PassThrough
to False and reset IsPeer back to False afterwards. Not sure if that would
work, I have never used an SSLIOHandler in this manner before.

I'm very curious why the device, being a TCP server, is initiating the handshake
as an SSL client instead of acting as an SSL server like most TCP servers
do. Do you know why the device is backwards like that?

--
Remy Lebeau (TeamB)
Marcel Uhlich

Posts: 5
Registered: 9/29/07
Re: SSL via already running TCP/IP Connection  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Apr 16, 2015 1:22 AM   in response to: Marcel Uhlich in response to: Marcel Uhlich
Hi remy,

it works as you suggested. I wonder if there is some sort of timing problem though. Is it possible that the SSL Handshake can be initiated before i set the IsPeer property to true ?

greetings

Marcel Uhlich wrote:
Hi Remy,

i will try what you have recommended and give the results here, but for now: The hardware company that is building the device only had access to a SSL Client hardware component. Therefore we decided to set up the PC as SSL Server. The device itself is some kind of passive data storage and the PC Software shall access the data actively. Therefore the device listens for incoming connection attempts and thus is the TCP Server.

Remy Lebeau (TeamB) wrote:
Marcel wrote:

i was able to do as you recommended but i needed to set
the "IsPeer" property of the ioHandler to true additionally.

Yes, good catch. The IOHandler needs that in order to call SSL_accept()
instead of ssl_connect().

However, you do need to be careful with setting IsPeer manually. IsPeer
is primarily intended to be True only on a server-side (TIdTCPServer) IOHandler,
not a client-side (TIdTCPClient) IOHandler. There are some internal resources
that are not released when IsPeer is True because they are owned by something
other than the IOHandler. On the other hand, the more I think of it, it
might actually be a bug that the IOHandler is calling SSL_accept() vs SSL_connect()
based on IsPeer rather than SSLOptions.Mode, at least for sslmClient and
sslmServer (I suppose sslmBoth would have to still rely on IsPeer).

So, to avoid any leaks on a client-side IOHandler, you might need to set
PassThrough to True initially and leave IsPeer as False, then establish the
underlying TCP connection, then set IsPeer to True before setting PassThrough
to False and reset IsPeer back to False afterwards. Not sure if that would
work, I have never used an SSLIOHandler in this manner before.

I'm very curious why the device, being a TCP server, is initiating the handshake
as an SSL client instead of acting as an SSL server like most TCP servers
do. Do you know why the device is backwards like that?

--
Remy Lebeau (TeamB)
Remy Lebeau (Te...


Posts: 9,447
Registered: 12/23/01
Re: SSL via already running TCP/IP Connection  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Apr 16, 2015 10:35 AM   in response to: Marcel Uhlich in response to: Marcel Uhlich
Marcel wrote:

Is it possible that the SSL Handshake can be initiated
before i set the IsPeer property to true ?

On the device side, it will. But if PassThrough is still True on your client
side when you assign IsPeer, the handshake has not been read by your client
yet, as TIdSSLIOHandlerSocketOpenSSL.OpenEncodedConnection() is not called
until you set PassThrough to False.

--
Remy Lebeau (TeamB)
Legend
Helpful Answer (5 pts)
Correct Answer (10 pts)

Server Response from: ETNAJIVE02