a couple of newbie questions regarding ssl lib

2005-11-19 Thread Chong Peng

dear all:

i am new to the open ssl library, after a couple of days source code reading, 
my understanding is that one can either use bio (come with the open ssl lib) or 
standard socket interface to connect ssl protocol to the underlying tcp 
protocol, if i would like to use standard socket to do that, the basic flow is 
as follows:

as tcp client:

socket --- connect (blocked!) --- SSL_new   --- SSL_write
SSL_set_fd SSL_read 
(blocked!)
SSL_connect (blocked!)

as tcp server:

socket --- accept (blocked!) --- SSL_new--- SSL_write
bind   SSL_set_fd  SSL_read 
(blocked!)
listen SSL_accept (blocked!)  

the SSL_connect/SSL_accept implement a (pretty complicate) state machine that 
is used to do the ssl handshaking, for that purpose, these two functions are 
blocked multiple times on the underlying socket id. after 
SSL_connect/SSL_accept returns, the corresponding ssl link is established and 
ready for io. in the io phase, SSL_read will again be blocked on the undelying 
socket id until data for that link is available.

the questions i have are:

1. do i understand right? 
2. if my understanding is correct, standard socket works pretty well in this 
picture. why we still need bio? what are things that the bio can do and the 
standard socket can not?
3. anybody know if there is any doc available about the state machines 
implemented in SSL_connect/SSL_accept?

thanks a lot.

chong peng
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]


Re: a couple of newbie questions regarding ssl lib

2005-11-19 Thread Dr. Stephen Henson
On Sat, Nov 19, 2005, Chong Peng wrote:

 
 dear all:
 
 i am new to the open ssl library, after a couple of days source code
 reading, my understanding is that one can either use bio (come with the open
 ssl lib) or standard socket interface to connect ssl protocol to the
 underlying tcp protocol, if i would like to use standard socket to do that,
 the basic flow is as follows:

Well whatever technique you use it still ends up using a BIO. Its is just that
when you tell the ssl library to use a socket it sets up a socket BIO
internally.

Steve.
--
Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage
OpenSSL project core developer and freelance consultant.
Funding needed! Details on homepage.
Homepage: http://www.drh-consultancy.demon.co.uk
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]


RE: a couple of newbie questions regarding ssl lib

2005-11-19 Thread mclellan, dave
I'm far from an expert, but your flow below seems mostly right.  What you
describe is how we have used SSL in our application.  We do not use BIOs for
a number of reasons, one of which is that we have an existing non-SSL
application over which we laid SSL.  The initial sequence of system calls
(that is, accept and connect, initial handshake) is followed by the SSL
sequences. BIOs seemed unnecessary for our situation, but I can see where
there are scenarios where BIOs are the cool way to go. 

Also, when I last looked, using BIOs seemed to preclude IPv6 addressing.  So
using raw system calls followed by SSLconnect/accept could be done without
regard to IP protocol.   

The SSL protocol is well-defined and books describe many aspects of it.
Google SSL and TLS and you'll find the good ones.  If you really need to
care about the connect/accept state machine (do you really?)  

FWIW.  

Dave McLellan - Consulting Software Engineer
Storage Platforms, Enablers, and Applications
EMC Corporation
228 South St. 
Hopkinton MA 01748
phone: 508-249-1257
fax 508-497-8030

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Chong Peng
Sent: Saturday, November 19, 2005 1:46 PM
To: openssl-users@openssl.org
Subject: a couple of newbie questions regarding ssl lib


dear all:

i am new to the open ssl library, after a couple of days source code
reading, my understanding is that one can either use bio (come with the open
ssl lib) or standard socket interface to connect ssl protocol to the
underlying tcp protocol, if i would like to use standard socket to do that,
the basic flow is as follows:

as tcp client:

socket --- connect (blocked!) --- SSL_new   --- SSL_write
SSL_set_fd SSL_read
(blocked!)
SSL_connect (blocked!)

as tcp server:

socket --- accept (blocked!) --- SSL_new--- SSL_write
bind   SSL_set_fd  SSL_read
(blocked!)
listen SSL_accept (blocked!)  

the SSL_connect/SSL_accept implement a (pretty complicate) state machine
that is used to do the ssl handshaking, for that purpose, these two
functions are blocked multiple times on the underlying socket id. after
SSL_connect/SSL_accept returns, the corresponding ssl link is established
and ready for io. in the io phase, SSL_read will again be blocked on the
undelying socket id until data for that link is available.

the questions i have are:

1. do i understand right? 
2. if my understanding is correct, standard socket works pretty well in this
picture. why we still need bio? what are things that the bio can do and the
standard socket can not?
3. anybody know if there is any doc available about the state machines
implemented in SSL_connect/SSL_accept?

thanks a lot.

chong peng
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]


RE: a couple of newbie questions regarding ssl lib

2005-11-19 Thread mclellan, dave
Woops.   What I meant instead of Google is Amazon - they, along with many
other booksellers have the good ones. 

Here are two that helped me: 

O'Reilly (John Viega):  Network Security with OpenSSL 
Eric Recorla's: SSL and TLS: Desinging and Building Secure Systems

FWIW2

Dave McLellan - Consulting Software Engineer
Storage Platforms, Enablers, and Applications
EMC Corporation
228 South St. 
Hopkinton MA 01748
phone: 508-249-1257
fax 508-497-8030

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of mclellan, dave
Sent: Saturday, November 19, 2005 3:46 PM
To: 'openssl-users@openssl.org'
Subject: RE: a couple of newbie questions regarding ssl lib

I'm far from an expert, but your flow below seems mostly right.  What you
describe is how we have used SSL in our application.  We do not use BIOs for
a number of reasons, one of which is that we have an existing non-SSL
application over which we laid SSL.  The initial sequence of system calls
(that is, accept and connect, initial handshake) is followed by the SSL
sequences. BIOs seemed unnecessary for our situation, but I can see where
there are scenarios where BIOs are the cool way to go. 

Also, when I last looked, using BIOs seemed to preclude IPv6 addressing.  So
using raw system calls followed by SSLconnect/accept could be done without
regard to IP protocol.   

The SSL protocol is well-defined and books describe many aspects of it.
Google SSL and TLS and you'll find the good ones.  If you really need to
care about the connect/accept state machine (do you really?)  

FWIW.  

Dave McLellan - Consulting Software Engineer
Storage Platforms, Enablers, and Applications
EMC Corporation
228 South St. 
Hopkinton MA 01748
phone: 508-249-1257
fax 508-497-8030

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Chong Peng
Sent: Saturday, November 19, 2005 1:46 PM
To: openssl-users@openssl.org
Subject: a couple of newbie questions regarding ssl lib


dear all:

i am new to the open ssl library, after a couple of days source code
reading, my understanding is that one can either use bio (come with the open
ssl lib) or standard socket interface to connect ssl protocol to the
underlying tcp protocol, if i would like to use standard socket to do that,
the basic flow is as follows:

as tcp client:

socket --- connect (blocked!) --- SSL_new   --- SSL_write
SSL_set_fd SSL_read
(blocked!)
SSL_connect (blocked!)

as tcp server:

socket --- accept (blocked!) --- SSL_new--- SSL_write
bind   SSL_set_fd  SSL_read
(blocked!)
listen SSL_accept (blocked!)  

the SSL_connect/SSL_accept implement a (pretty complicate) state machine
that is used to do the ssl handshaking, for that purpose, these two
functions are blocked multiple times on the underlying socket id. after
SSL_connect/SSL_accept returns, the corresponding ssl link is established
and ready for io. in the io phase, SSL_read will again be blocked on the
undelying socket id until data for that link is available.

the questions i have are:

1. do i understand right? 
2. if my understanding is correct, standard socket works pretty well in this
picture. why we still need bio? what are things that the bio can do and the
standard socket can not?
3. anybody know if there is any doc available about the state machines
implemented in SSL_connect/SSL_accept?

thanks a lot.

chong peng
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]


Re: a couple of newbie questions regarding ssl lib

2005-11-19 Thread Alain Damiral

Hi there,

Your second question happens to concern what I'm working on right now. 
Sometimes rather than developping an application on top (think layer 
architecture) of OpenSSL, you might want to give your application 
control over the network access but still use OpenSSL as a security 
module that doesn't encapsulate communication. A generic illustration of 
this kind of scenario is given in the documentation for BIO pairs.


In my case, I have an API to build applications over a structured 
peer-to-peer network. I want to use OpenSSL for security but I want to 
use this structured network instead of TCP as SSL/TLS's transport layer. 
Then BIOs and BIO pairs are the way to go. (ssltest.c is the place to 
dive into if you ever want to figure out how to use these). Another 
elegant way of doing this is to write a custom BIO...


I hope this helps !

Regards,


Chong Peng wrote:


dear all:

i am new to the open ssl library, after a couple of days source code reading, 
my understanding is that one can either use bio (come with the open ssl lib) or 
standard socket interface to connect ssl protocol to the underlying tcp 
protocol, if i would like to use standard socket to do that, the basic flow is 
as follows:

as tcp client:

socket --- connect (blocked!) --- SSL_new   --- SSL_write
   SSL_set_fd SSL_read 
(blocked!)
   SSL_connect (blocked!)

as tcp server:

socket --- accept (blocked!) --- SSL_new--- SSL_write
bind   SSL_set_fd  SSL_read 
(blocked!)
listen SSL_accept (blocked!)  


the SSL_connect/SSL_accept implement a (pretty complicate) state machine that 
is used to do the ssl handshaking, for that purpose, these two functions are 
blocked multiple times on the underlying socket id. after 
SSL_connect/SSL_accept returns, the corresponding ssl link is established and 
ready for io. in the io phase, SSL_read will again be blocked on the undelying 
socket id until data for that link is available.

the questions i have are:

1. do i understand right? 
2. if my understanding is correct, standard socket works pretty well in this picture. why we still need bio? what are things that the bio can do and the standard socket can not?

3. anybody know if there is any doc available about the state machines 
implemented in SSL_connect/SSL_accept?

thanks a lot.

chong peng
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]
 




--
Alain Damiral,

Université Catholique de Louvain - student
alain.damiral'at'student.info.ucl.ac.be

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]