RE: SSL_connect and SSL_accept
I am unable to think of a scenerio why ur case is possible unless some serious network congestion has developed and pkts were lost..i dont see how..but the experts might able to give u a better idea. You get a SYN, send a SYN ACK, other side sends an ACK, then the other side's Internet connection goes down due to an extended power failure. You will be waiting for it to send the first SSL handshake message forever. Blocking function block until the operation completes, fails, or it is proven impossible for it to ever succeed. DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Key files in dat formats
I have a SSL server application in which the certificate file is rsa.der and key file rsakey.dat. There is no standard key file format that uses a '.dat' extension that I know of. What is the *.dat format? How does it differ from pem and der formats? How do we generate one with OpenSSL? I would suggest reading the server's documentation and seeing what format it wants its key in. Alternatively, you could try various different formats to see what works. DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Regarding ssl3_mac
Gayathri Sundar wrote: Can someone give me inputs on the function ssl3_mac, especially where it is called s-method-ssl3_enc-mac(s,(p[wr-length]),1); I need to know what p[wr-length] is pointing to and why we do a digest update of 2 bytes from that. The code is taken from s3_pkt.c function ssl3_write_bytes. Thanks --Gayathri i hope u meant in 'do_ssl3_write()'. p[wr-length] is pointing to the place just after your data. this is where you want the mac to be placed. if you look at ssl3_mac(), the second param is the o/p param. where exactly is it in the code is it that you mentioned update of 2 bytes being done? -jb -- mathematician, n.: Some one who believes imaginary things appear right before your i's. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: SSL_connect and SSL_accept
Yes, I agree with you, but then why would the CLIENT get an ERROR? 2) The client calls SSL_connect(). The underlying socket is in blocking mode 3) SSL_connect() returns error. 4) The server does not notice this, and continues to wait in SSL_accept(). if SSL_connect indeed has returned with ERROR..then the SSL_accept should also return with an ERROR, unless the data transmission was LOST!!! In ur case the CLIENT will go on retrying sending the same message with the TCP retransmitting the pkt as no ACK was received on the client side..and if I am correct..it tries 3 times on linux and returns with an error..so it does not block FOREVER..there is no concept of blocking FOREVER..literally.. yes but then NON BLOCKING sockets are ofcourse the best solution esp when ur appliance is designed for the enterprise markets. Thanks --Gayathri I am unable to think of a scenerio why ur case is possible unless some serious network congestion has developed and pkts were lost..i dont see how..but the experts might able to give u a better idea. You get a SYN, send a SYN ACK, other side sends an ACK, then the other side's Internet connection goes down due to an extended power failure. You will be waiting for it to send the first SSL handshake message forever. Blocking function block until the operation completes, fails, or it is proven impossible for it to ever succeed. DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] This email message (including any attachments) is for the sole use of the intended recipient(s) and may contain confidential, proprietary and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please immediately notify the sender by reply email and destroy all copies of the original message. Thank you. Intoto Inc. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Regarding ssl3_mac
Thanks jimmy..I realised that much, the update is happening from ssl3_mac defined in s3_enc.c, some s2n of the length is called, followed by a digestupdate(md, 2)..in case of READ, md is an empty array..why do we copy the ssl record length into a temp var p and then do a s2n followed by an digest update? Thanks --Gayathri Gayathri Sundar wrote: Can someone give me inputs on the function ssl3_mac, especially where it is called s-method-ssl3_enc-mac(s,(p[wr-length]),1); I need to know what p[wr-length] is pointing to and why we do a digest update of 2 bytes from that. The code is taken from s3_pkt.c function ssl3_write_bytes. Thanks --Gayathri i hope u meant in 'do_ssl3_write()'. p[wr-length] is pointing to the place just after your data. this is where you want the mac to be placed. if you look at ssl3_mac(), the second param is the o/p param. where exactly is it in the code is it that you mentioned update of 2 bytes being done? -jb -- mathematician, n.: Some one who believes imaginary things appear right before your i's. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] This email message (including any attachments) is for the sole use of the intended recipient(s) and may contain confidential, proprietary and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please immediately notify the sender by reply email and destroy all copies of the original message. Thank you. Intoto Inc. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Really confusing with SSL_write
Hi, I've been trying to figure out (plus testing) how to actually use SSL_write. I write alot of data and have an internal Send Queue in which I keep packets. I try to follow this reasoning: 1) try to write the entire chunk with SSL_write if it returns the same value as 'len' then it succeeded. otherwise: 2) add it to a sendqueue, and send it again later on using SSL_write(ssl, sendqueue-packet + written , len -written) and then I check to see if the returned value equals len-written. I have enabled PARTIAL_WRITE and allow moving addresses.. Is this wrong? I think I have read all over the place that you should send the same params. Should I ALWAYS just send: SSL_write(ssl,sendqueue-packet, len); I saw inside s3_pkt.c that it seemed to have an internal send queue really similar to mine. But if the latter version is the correct version, what return value am I to expect? 'len' or the number of bytes actually written at that specific call ? Btw, I am using NON BLOCKING SOCKETS. ANY help/pointers is mostly appreciated Thanks in advance (Is all this true for SSL_read aswell? and am I right to assume that I don't need to bother with this when dealing with blocking sockets? (not an option for my server, but for the clients) ) /Tommy Wallberg __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: SSL_connect and SSL_accept
Urjit., 1st of all theoritically your are 100% correct, after all SSL runs in the SESSION layer, but it depends on the underlying transport connection, and if that has problems, SSL has problems. Now Am not sure why you expect the TCP connection to be A-OK and still get an SSL_connect failure. If the failure is with the HANDSHAKE, like mismatch in version/cipher suite or something the SSL ALERT RECORD will take care and eventually close the connection. The only case is what David says, if the peer has been disconnected coz of some power/network failure, then the client will succeed in SENDING the Handshake message but never receive any ACK, so the TCP will endup doing retransmissions. SSL_connect WILL NOT return with ERRORS in this case. Its all blocked, I agree, but YOUR scenerio of SSL_CONNECT failing and SSL_ACCEPT not knowing that CANNOT happen. SSL_connect will SUCCEED and BLOCK indifinitely, waiting for a PEER ACK, and the server will not even be alive. If the server was ALIVE, why would it not respond. Go for Non Blocking sockets, if that suits your requirement, but your scenerio cannot happen in blocking mode, infact if your scenerio does happen, then even in non blocking mode it will end up looping, only difference is between successive POLLs ur application has control, there will be a loop between ur SELECT and SSL_CONNECT, latter always retruning some TRANSIENT retry errors. Probably u could have a count and cleanup.. I dont see how Non Block will solve ur problem, IF it can occur. Thanks --Gayathri I believe you are confusing tcp/ip connection establishment and SSL session establishment. As far as my understanding goes: SSL is an application level protocol, that works on an existing tcp channel. So, SSL handshake can be thought of as two network applications talking to each other. It is obvious that, the moment first SSL handshake packet reaches the server, the server would change its state and will now start with the handshake. If anything goes wrong hereafter (Invalid packet, tcp error, lost packet ... ), the server's SSL_accept will detect that and report error. The problem may occur when: 1) Server is waiting for first SSL handshake packet in SSL_accept 2) Client attempts to establish SSL handshake with SSL_connect 3) SSL_connect fails even before it could send the first SSL handshake packet. So the client has put nothing on the network. Now, SSL_connect has returned an error in the client, and the server is still blocked in SSL_accept. Gayathri, You are correct about first forking and then attempting SSL_accept. This will save the main server from blocking into SSL_accept and failing to server other client connection requests. Here the forked child will be blocked in SSL_accept though. David, As I have already acknowledged in my previous post, the option of using non blocking socket seems to be the way to go. I have a few doubts on how a particular scenario can be handled, but I feel it is a bit off track with respect to the current thread. So I will send a new post for that. Thank you everyone for responding. ~ Urjit - Original Message - From: Gayathri Sundar [EMAIL PROTECTED] To: openssl-users@openssl.org Sent: Thursday, March 29, 2007 1:02 PM Subject: RE: SSL_connect and SSL_accept Yes, I agree with you, but then why would the CLIENT get an ERROR? 2) The client calls SSL_connect(). The underlying socket is in blocking mode 3) SSL_connect() returns error. 4) The server does not notice this, and continues to wait in SSL_accept(). if SSL_connect indeed has returned with ERROR..then the SSL_accept should also return with an ERROR, unless the data transmission was LOST!!! In ur case the CLIENT will go on retrying sending the same message with the TCP retransmitting the pkt as no ACK was received on the client side..and if I am correct..it tries 3 times on linux and returns with an error..so it does not block FOREVER..there is no concept of blocking FOREVER..literally.. yes but then NON BLOCKING sockets are ofcourse the best solution esp when ur appliance is designed for the enterprise markets. Thanks --Gayathri I am unable to think of a scenerio why ur case is possible unless some serious network congestion has developed and pkts were lost..i dont see how..but the experts might able to give u a better idea. You get a SYN, send a SYN ACK, other side sends an ACK, then the other side's Internet connection goes down due to an extended power failure. You will be waiting for it to send the first SSL handshake message forever. Blocking function block until the operation completes, fails, or it is proven impossible for it to ever succeed. DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: SSL_connect and SSL_accept
Urjit Gokhale wrote: I believe you are confusing tcp/ip connection establishment and SSL session establishment. ... and you should also remember that a reliable transport is a prerequisite for tls. The problem may occur when: 1) Server is waiting for first SSL handshake packet in SSL_accept 2) Client attempts to establish SSL handshake with SSL_connect 3) SSL_connect fails even before it could send the first SSL handshake packet. So the client has put nothing on the network. Now, SSL_connect has returned an error in the client, and the server is still blocked in SSL_accept. i believe your problem maybe the case when a TCP session is in place but an SSL session is not started (client problems or a malicious client trying to DoS you). A timeout maybe what you are looking for. You could rely on tcp's timeout (if no data is sent TCP_KEEPALIVE isn't selected, it should timeout) or have your own application timer to keep server resource's from being wasted by a incomplete sessions. -jb __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: SSL_connect and SSL_accept
Hmm... I am surprised to see how I have managed to confuse you. I thought my previous post was pretty clear. Anyway, I will try to explain again. The client and server have and existing tcp connection, which is healthy. There is no problem with the tcp connection throughout the scenario. The client, for some reason decides to have a secured session, and so with its own protocol, tells the server to allow a secured session. After seeing such request from client (This is still a tcp communication, SSL is still not in picture), the server creates a SSL object, calls SSL_set_fd(sock_serv) and then calls SSL_accept The Client creates its SSL object, calls SSL_set_fd(sock_cli) and calls SSL_connect() Now *before* SSL_connect can actually write something on the tcp channel, using tcp send() or write(), something goes wrong and it returns an error to its caller. So there is nothing placed on the tcp channel. The server is waiting for the SSL handshake packet which it never get because SSL_connect() could never send it. Hope the scenario I am talking about is clear now. The reason why I am interested in knowing if something like what is written above can happen is: I want my client and server to be able to communicate with/without SSL If the SSL session establishment fails, the client/server can decide to kill the underlying tcp channel, or can decide to go ahead unsecured. In the scenario mentioned above, the client knows that SSL session establishment has failed, because SSL_connect() returned an error. So it may, as per its configuration decide to go ahead with unsecured communication. On he other side of the tcp link, the server is still waiting for SSL handshake packet, which the client was expected to send, which the client never sent due to some error. So here is the problem. I want my server to detect that something went wrong with the client and it should fall back to the unsecured communication. The issue here is HOW can my server detect the SSL_connect() failure that occurred on the client side? Anything that the client would send after SSL_connect() failure, will in fact be taken up by SSL_accept() and SSL_accept() will now error out saying it read invalid SSL handshake packet. Now as I write down this whole thing, I wonder if even non-blocking sockets can help. Does it look more like a design issue ? ~ Urjit - Original Message - From: Gayathri Sundar [EMAIL PROTECTED] To: openssl-users@openssl.org Sent: Thursday, March 29, 2007 4:07 PM Subject: Re: SSL_connect and SSL_accept Urjit., 1st of all theoritically your are 100% correct, after all SSL runs in the SESSION layer, but it depends on the underlying transport connection, and if that has problems, SSL has problems. Now Am not sure why you expect the TCP connection to be A-OK and still get an SSL_connect failure. If the failure is with the HANDSHAKE, like mismatch in version/cipher suite or something the SSL ALERT RECORD will take care and eventually close the connection. The only case is what David says, if the peer has been disconnected coz of some power/network failure, then the client will succeed in SENDING the Handshake message but never receive any ACK, so the TCP will endup doing retransmissions. SSL_connect WILL NOT return with ERRORS in this case. Its all blocked, I agree, but YOUR scenerio of SSL_CONNECT failing and SSL_ACCEPT not knowing that CANNOT happen. SSL_connect will SUCCEED and BLOCK indifinitely, waiting for a PEER ACK, and the server will not even be alive. If the server was ALIVE, why would it not respond. Go for Non Blocking sockets, if that suits your requirement, but your scenerio cannot happen in blocking mode, infact if your scenerio does happen, then even in non blocking mode it will end up looping, only difference is between successive POLLs ur application has control, there will be a loop between ur SELECT and SSL_CONNECT, latter always retruning some TRANSIENT retry errors. Probably u could have a count and cleanup.. I dont see how Non Block will solve ur problem, IF it can occur. Thanks --Gayathri I believe you are confusing tcp/ip connection establishment and SSL session establishment. As far as my understanding goes: SSL is an application level protocol, that works on an existing tcp channel. So, SSL handshake can be thought of as two network applications talking to each other. It is obvious that, the moment first SSL handshake packet reaches the server, the server would change its state and will now start with the handshake. If anything goes wrong hereafter (Invalid packet, tcp error, lost packet ... ), the server's SSL_accept will detect that and report error. The problem may occur when: 1) Server is waiting for first SSL handshake packet in SSL_accept 2) Client attempts to establish SSL handshake with SSL_connect 3) SSL_connect fails even before it could send the first SSL handshake packet. So the client has put nothing on the network. Now, SSL_connect has returned an error in the
Certificate verification
Hello. I am currently reading John Viega et al. (The Oreilly book) on the chapter that focuses of the on the creation of certificates. Basically, in the server2 / client2 example, the client won't accept the server's certificate. I hope that this will not be too Oreilly specific, but if you have this example handy on you desk, it might help you help me on the subject. But I send pages and pages of certs and code for all to check, I would like to know a few things about creating PEM files and checking them indenpendently. 1) Does a PEM have an order ? Does the certificate come before the key or after ? Does a CA's certificate come before / after the issuer's cert ? In the example, PEM's are always cat'ted starting with a the issuer certs, then his private key, the CA's cert. like so. cat clientcert.pem clientkey.pem rootcert.pem client.pem 2) How can I check if root.pem is the signer of client.pem. It this the right way ? % openssl verify -CAfile rootcert.pem client.pem % client.pem: OK Can I expect that this will be valid with any other PEM signed with the root CA ? 3) The book also starts with a pretty strict example using SSL_CTX_verify_locations which I believe is the source of all my problems so far (and the message returned by openssl is pretty cryptic). So all the questions below are based on this function. Since I'm not in a production box, with no FQDN, how should I set up my commonName and dNSName in my openssl.cnf to make it work ? - Should I sign with 'localhost' on all my certs if I run both client and server on my box ? - What about a on a LAN, will an IP address do, signing the server cert with 192.168.0.3 and the client cert with 192.168.0.5 ? or must I set up bogus names in my /etc/hosts file ? - Even if the root CA is outside of my network, will the client trust the cert sent by the server even if I can't access the root CA's site as long as I have the root's cert on the client side ? Thanks for reading this. Hope it wasn't a pain. Regards. Marc St-Jacques
Re: Cannot convert 'des_ks_struct ( *)[16]' to 'des_ks_struct *' ??
Hello,
thanks for helping. i tried compiling the source code u gave me but it
returns the same error, which is:
[C++ Error] testDes.cpp(23): E2034 Cannot convert 'des_ks_struct
( *)[16]' to 'des_ks_struct *'
[C++ Error] testDes.cpp(23): E2342 Type mismatch in parameter
'schedule' (wanted 'des_ks_struct *', got 'des_ks_struct ( *)[16]').
On Unix this works without problem, maybe try to compile this
using C, not C++ ?
Anyway to be honest, i don't really know what's happening inside your
source code (as well as mine). What do all these things
unsigned char key08[] = {0,1,2,3,4,5,6,7};
unsigned char key16[] = {0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15};
unsigned char key24[] =
{0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23};
unsigned char key32[] =
{0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31};
unsigned char iv[] = {0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15};
unsigned char inbuf[1024]=abcdefg\x01;
unsigned char outbuf[1024];
=
means? what does all the number represents? and at the inbuf
variable, what does \x01 means?
In this code I use only key24 and iv variable.
key24 represents 24 bytes long secure des3 key.
It is used to initialize des3 key schedules (in 8 bytes chunks).
I other words, when you use des3 you have to generate exactly
24 bytes long key. There are methods (like pkcs5) to generate
such sequences from user passwords (like bob1).
iv variable is called initialization vector and is used in CBC.
DES and DES3 encrypts data in 8 bytes blocks but function
DES_ede3_cbc_encrypt() does not use padding so this block
has 7 bytes of data and one of pad (0x01).
(for 6 bytes of data we should add two bytes 0x0202).
This padding is add for proper decryption with openssl binary.
I'm really new to all this encryption things, and really hope you
could help me understand all this. Or if you don't mind, could you
lead me to anyway i can learn all this?
You may look at http://en.wikipedia.org/wiki/Block_cipher
In OpenSSL there is high-level API called EVP (envelope)
which is simple and works with padding.
Simple example attached.
After looking at your source second time:
You should not fill key schedule in that way, I assume
that:
AnsiString myKey = test1234;
declares eight bytes string but:
myKey.SubString(1,8).c_str()
myKey.SubString(9,8).c_str() - ???
myKey.SubString(17,8).c_str() - ???
Best regards,
--
Marek Marcola [EMAIL PROTECTED]
#include stdio.h
#include string.h
#include openssl/evp.h
int main(int argc, char *argv[])
{
unsigned char key[] = {0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23};
// unsigned char key[] = {0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15};
unsigned char iv[] = {1,2,3,4,5,6,7,8};
unsigned char inbuf[1024];
unsigned char outbuf[1024];
int outlen;
int n;
EVP_CIPHER_CTX ctx;
EVP_CIPHER_CTX_init(ctx);
EVP_EncryptInit_ex(ctx, EVP_des_ede3_cbc(), NULL, key, iv);
// EVP_EncryptInit_ex(ctx, EVP_bf_cbc(), NULL, key, iv);
//printf(cipher parameters: \n);
//printf(block size: %d\n, EVP_CIPHER_CTX_block_size(ctx));
//printf(key length: %d\n, EVP_CIPHER_CTX_key_length(ctx));
//printf( iv length: %d\n, EVP_CIPHER_CTX_iv_length(ctx));
while(1){
if( (n=fread(inbuf, 1, 128, stdin)) = 0 ){
break;
}
if(!EVP_EncryptUpdate(ctx, outbuf, outlen, inbuf, n)){
return(0);
}
fwrite(outbuf, 1, outlen, stdout);
}
if(!EVP_EncryptFinal_ex(ctx, outbuf, outlen)){
return(0);
}
fwrite(outbuf, 1, outlen, stdout);
EVP_CIPHER_CTX_cleanup(ctx);
return(0);
}
error in SSLv3 flush data
Hi, I have trouble getting openldap clients to connect to an openldap server; when the connection is opened, the server says error in SSLv3 flush data and the client hangs. This happens only for connections through the network (local connections work without problem), and whether it occurs or not depends on the debug level (for example, if -d2 is used on slapd, the problem does not occur). It's not certain that the problem is in OpenSSL, but I need some help anyway in order to debug it further and narrow it down. The server is Debian etch, with all software being packaged by Debian: OpenLDAP 2.3.30 and OpenSSL 0.9.8c. There is identical behaviour with two clients: a Debian etch and a Ubuntu 6.10. I tried compiling OpenLDAP 2.3.32 from upstream (against Debian's shared libssl), and there was the same problem. I also tried compiling OpenSSL 0.9.8e (with ./config shared) and put the resulting shared library in place of Debian's, and run Debian's OpenLDAP 2.3.30, and again I have the same problem. Then, I tried to look at the code to find about more about what error in SSLv3 flush data means and why and where it occurs. But I don't quite understand the code, of course. In bio_lib.c, BIO_ctrl runs with cmd=SSL3_ST_SW_FLUSH, with b being a buffer (type 0x209). When it reaches the line ret=b-method-ctrl(b,cmd,larg,parg); control goes over to buffer_ctrl in bf_buff.c. It goes to case BIO_CTRL_FLUSH: from where it runs BIO_write(b-next_bio, ...). Now b-next_bio is sockbuf glue, which I don't know what it means, and its type, 0x464, is not listed in bio.h, so I don't get it. In any case, if I enable the debugging fprintf command, its result is FLUSH [ 0] 1603 - -1 The problem does not manifest all the time. The first time I try a request after starting slapd, it's _usually_ OK, and the next times it's _usually_ as described. Could you tell me if I'm on the right track and how to proceed? Needless to say I'm not much interested in digging in the code - my only motivation is to get it to work, so if there's an easier path, I'd prefer it. Previous reports on this issue: http://www.mail-archive.com/openldap-software@openldap.org/msg08065.html http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=412706 Thanks for any help! __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Installing new certificate replacing expired cert.
First off I'm a complet noob here. I don't do open source and I'm not a programmer. I have been handed a job that goes something like this. A webserver has a certificate that has expired. Openssl was used to create the cert, and is used as a proxy of some sort to handle redirects. I have renewed the certificate but have no clue how to get it installed where it needs to be. If you go to the website in question it still gives notification that the certificate is expired. Any information needed I can likely provide but as I said I'm a total noob to this openssl thing.
SSL_get_verify_result
I need some help with SSL_get_verify_result errors.
I use WindowsXP, Visual C++, OpenSll 0.9.8d
this is my example program:
#include stdio.h
#include string.h
int main(int argc, char *argv[])
{
BIO * bio;
SSL * ssl;
SSL_CTX * ctx;
int p;
char * request = GET /...;
char r[1024];
SSL_library_init();
/* Set up the library */
ERR_load_BIO_strings();
SSL_load_error_strings();
OpenSSL_add_all_algorithms();
/* Set up the SSL context */
ctx = SSL_CTX_new(SSLv23_client_method());
/* Load the trust store */
if(! SSL_CTX_load_verify_locations(ctx, TrustStore.pem,
C:\build\openssl-0.9.8d\certs))
{
fprintf(stderr, Error loading trust store\n);
ERR_print_errors_fp(stderr);
SSL_CTX_free(ctx);
return 0;
}
/* Setup the connection */
bio = BIO_new_ssl_connect(ctx);
/* Set the SSL_MODE_AUTO_RETRY flag */
BIO_get_ssl(bio, ssl);
SSL_set_mode(ssl, SSL_MODE_AUTO_RETRY);
/* Create and setup the connection */
BIO_set_conn_hostname(bio, the host I use:https);
if(BIO_do_connect(bio) = 0)
{
fprintf(stderr, Error attempting to connect\n);
ERR_print_errors_fp(stderr);
BIO_free_all(bio);
SSL_CTX_free(ctx);
return 0;
}
/* Check the certificate */
if(SSL_get_verify_result(ssl) != X509_V_OK)
{
fprintf(stderr, Certificate verification error: %i\n,
SSL_get_verify_result(ssl));
BIO_free_all(bio);
SSL_CTX_free(ctx);
return 0;
}
/* Send the request */
BIO_write(bio, request, strlen(request));
/* Read in the response */
for(;;)
{
p = BIO_read(bio, r, 1023);
if(p = 0) break;
r[p] = 0;
printf(%s, r);
}
/* Close the connection and free the context */
BIO_free_all(bio);
SSL_CTX_free(ctx);
return 0;
}
I am trying to connect to two diferent hosts... and i get diferent errors:
from the first: Certificate verification error: 19
the second: Certificate verification error: 20
I am using the same TrustStore.pem for both of them...
but I can connect without a problem to for example: www.verisign.com
I dont have experience on SSL, so please, answer me saying specifics things
to follow.
Maria
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
API functions for DTLS?
From http://www.openssl.org/news/news.html, I learned that support for DTLS was introduced in OpenSSL 0.9.8. I've been looking for the API functions that relate to DTLS, but could not find any in the documentation at http://www.openssl.org/docs/ssl/ssl.html - Did the added support for DTLS introduce new API's? - If so, (where) have they been documented? - If not, is there a difference in usage of the existing TLS API's between securing TCP and securing UDP? Thanks for any pointers/explanation, Erik Leunissen == __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: SSL_connect and SSL_accept
I am quite clear with your problem and am not confused. The only point I have been stressing from beginning is that SSL_connect due to WHATEVER error it returns a failure to the calling application, the peer WILL know for the simple fact that a socket send cannot fail unless the FD itself is not created/the host is not in the network/ or the interface is down or simply if the HOST runs out of MEMORY, I am not able to think of an error case wherein the SSL_connect fails to send a message out when the underlying TCP connection is ALIVE and KICKING. WHY? WHAT SORT OF ERROR ARE YOU ANTICIPATING that SSL_connect will return FAILURE to its application without even sending 1 byte on the wire? UNLESS SSL_INIT itself fails on the client or SSL OBJECT creation fails? If that is the FAILURE ur worried about then you might as well initiate a TCP teardown from the client and not attempt SSL anymore.. I hope I am able to explain better..see only in severe application programming errors/memory leak or whatever the SSL init itself will fail..so if the SSL init fails on the client side DONT initiate SSL at all so that the server will not go into SSL_accept. Why will SSL OBJ creation fail? CAN you explain to me WHAT ERROR UR TALKING ABOUT that SSL_CONNECT will return FAILURE TO CALLING APPLICATION without sending 1BYTE on the wire when the TCP CONNECTION IS A-OK? I can think of BUGGY CODING..and I dont think Non blocking will solve ur problem as its never going to detect this FAILURE THAT UR TALKING ABOUT..unless you implement POLL TIMEOUT i.e the FD will never SELECT as it never receives any DATA, so ur POLL TIMER should cleanup that FD if say it doesnt select within 5mins or so.. This is my solution: 1. Make ur FDs non blocking 2. Start a timer per FD basis before ur add it into ur POLL table 3. Everytime the FD selects on a POLLIN/POLLOUT restart ur timer 4. On TimerExpiration clean up that FD coz it never received any DATA for the timeout period, due to n/w or client failures. Decide on a good timeout value.. Thanks --Gayathri Hmm... I am surprised to see how I have managed to confuse you. I thought my previous post was pretty clear. Anyway, I will try to explain again. The client and server have and existing tcp connection, which is healthy. There is no problem with the tcp connection throughout the scenario. The client, for some reason decides to have a secured session, and so with its own protocol, tells the server to allow a secured session. After seeing such request from client (This is still a tcp communication, SSL is still not in picture), the server creates a SSL object, calls SSL_set_fd(sock_serv) and then calls SSL_accept The Client creates its SSL object, calls SSL_set_fd(sock_cli) and calls SSL_connect() Now *before* SSL_connect can actually write something on the tcp channel, using tcp send() or write(), something goes wrong and it returns an error to its caller. So there is nothing placed on the tcp channel. The server is waiting for the SSL handshake packet which it never get because SSL_connect() could never send it. Hope the scenario I am talking about is clear now. The reason why I am interested in knowing if something like what is written above can happen is: I want my client and server to be able to communicate with/without SSL If the SSL session establishment fails, the client/server can decide to kill the underlying tcp channel, or can decide to go ahead unsecured. In the scenario mentioned above, the client knows that SSL session establishment has failed, because SSL_connect() returned an error. So it may, as per its configuration decide to go ahead with unsecured communication. On he other side of the tcp link, the server is still waiting for SSL handshake packet, which the client was expected to send, which the client never sent due to some error. So here is the problem. I want my server to detect that something went wrong with the client and it should fall back to the unsecured communication. The issue here is HOW can my server detect the SSL_connect() failure that occurred on the client side? Anything that the client would send after SSL_connect() failure, will in fact be taken up by SSL_accept() and SSL_accept() will now error out saying it read invalid SSL handshake packet. Now as I write down this whole thing, I wonder if even non-blocking sockets can help. Does it look more like a design issue ? ~ Urjit - Original Message - From: Gayathri Sundar [EMAIL PROTECTED] To: openssl-users@openssl.org Sent: Thursday, March 29, 2007 4:07 PM Subject: Re: SSL_connect and SSL_accept Urjit., 1st of all theoritically your are 100% correct, after all SSL runs in the SESSION layer, but it depends on the underlying transport connection, and if that has problems, SSL has problems. Now Am not sure why you expect the TCP connection to be A-OK and still get an SSL_connect failure. If the failure is with the HANDSHAKE, like mismatch in version/cipher suite or something the SSL
