[openssl.org #2036] bug report: TLS session resumption not checking for existence of client finished message
[david.good...@g2microsystems.com - Tue Sep 08 09:45:22 2009]: However I was advised that it is not a bug in FreeRADIUS, since FreeRADIUS uses OpenSSL for the required functionality, and it was suggested that I report it to OpenSSL as a bug. I'm not sure this is an OpenSSL bug either. To use EAP IIRC you need to patch OpenSSL and use additional code to support it. I'd suggest contacting the patch/additional code author. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2033] [PATCH] DTLS Listen
[seggelm...@fh-muenster.de - Thu Sep 03 18:09:34 2009]: This patch adds the function dtls1_listen(SSL *s, struct sockaddr *client), as well as the user accessible macro DTLSv1_listen(). It is intended to be called with an SSL object with a listening socket. [snip to example] /* Wait for ClientHello with valid cookie (blocking) */ while (!DTLSv1_listen(ssl, client_addr)); Is the above just an example or would it always block, possibly indefinitely? If so is there some way this could work with non-blocking I/O? Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2033] [PATCH] DTLS Listen
Am 08.09.2009 um 18:15 schrieb Stephen Henson via RT: [seggelm...@fh-muenster.de - Thu Sep 03 18:09:34 2009]: This patch adds the function dtls1_listen(SSL *s, struct sockaddr *client), as well as the user accessible macro DTLSv1_listen(). It is intended to be called with an SSL object with a listening socket. [snip to example] /* Wait for ClientHello with valid cookie (blocking) */ while (!DTLSv1_listen(ssl, client_addr)); Is the above just an example or would it always block, possibly indefinitely? If so is there some way this could work with non- blocking I/O? That's just a simple example. If you use blocking sockets, it doesn't return until a ClientHello with a valid cookie has been received (returns 1) or an error occurred (returns 0). If you use non-blocking sockets, it always returns 0 on EAGAIN, so you can use select() to only call it when there's data to process and it will return as soon as there is nothing left. - Robin __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2033] [PATCH] DTLS Listen
[seggelm...@fh-muenster.de - Tue Sep 08 18:31:29 2009]: That's just a simple example. If you use blocking sockets, it doesn't return until a ClientHello with a valid cookie has been received (returns 1) or an error occurred (returns 0). If you use non-blocking sockets, it always returns 0 on EAGAIN, so you can use select() to only call it when there's data to process and it will return as soon as there is nothing left. Is there some reason you only return 0, 1 from the ctrl? I'm wondering why you can't just return the return value of SSL_accept() (is = 0) for consistency with similar calls. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2033] [PATCH] DTLS Listen
Am 08.09.2009 um 19:59 schrieb Stephen Henson via RT: [seggelm...@fh-muenster.de - Tue Sep 08 18:31:29 2009]: That's just a simple example. If you use blocking sockets, it doesn't return until a ClientHello with a valid cookie has been received (returns 1) or an error occurred (returns 0). If you use non-blocking sockets, it always returns 0 on EAGAIN, so you can use select() to only call it when there's data to process and it will return as soon as there is nothing left. Is there some reason you only return 0, 1 from the ctrl? I'm wondering why you can't just return the return value of SSL_accept() (is = 0) for consistency with similar calls. Well, I was thinking of just making a difference between valid ClientHello received and everything else. Just returning the return value of SSL_accept() would be ok in case it's = 0. Otherwise it returns 2 to differentiate the premature handshake routine exit because of listen from the regular handshake ending. So, also for consitency, the listen call should not return 2 but 1 then. However, when using listen the handhsake routine should never exit with 1, indicating a successful handshake. I'll submit an updated version of the patch tomorrow. - Robin __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2033] [PATCH] DTLS Listen
Am 08.09.2009 um 18:31 schrieb Robin Seggelmann via RT: Am 08.09.2009 um 18:15 schrieb Stephen Henson via RT: [seggelm...@fh-muenster.de - Thu Sep 03 18:09:34 2009]: This patch adds the function dtls1_listen(SSL *s, struct sockaddr *client), as well as the user accessible macro DTLSv1_listen(). It is intended to be called with an SSL object with a listening socket. [snip to example] /* Wait for ClientHello with valid cookie (blocking) */ while (!DTLSv1_listen(ssl, client_addr)); Is the above just an example or would it always block, possibly indefinitely? If so is there some way this could work with non- blocking I/O? That's just a simple example. If you use blocking sockets, it doesn't return until a ClientHello with a valid cookie has been received (returns 1) or an error occurred (returns 0). If you use non-blocking sockets, it always returns 0 on EAGAIN, so you can use select() to only call it when there's data to process and it will return as soon as there is nothing left. I forgot to mention that in the example above I have socket timeouts set. That's the reason why the listen call is in a loop to try again as soon as it returned because of EAGAIN. - Robin __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Bug in IP address parsing?..
Thanks for clarifying that, Stephen. Never use openssl's request racket. When I go to http://rt.openssl.org and use the Quick ticket creation option a the bottom of the page, I get an error: No permission to create tickets in the queue 'OpenSSL-Bugs'. Apparently I need some permission to generate an OpenSSL-Bugs ticket. The lone choice I have from the 'Queue' dropdown is OpenSSL-Bugs, so I am not sure how to submit this ticket. Can someone pl. point out the operator error here? Sorry, Vineet On Fri, Sep 4, 2009 at 3:16 PM, Dr. Stephen Henson st...@openssl.orgwrote: On Fri, Sep 04, 2009, Vineet Kumar wrote: I noticed in GENERAL_NAME_print() code the following parsing code which has a bug. When my test certificate's subjectAltName has IP Address: 2001::21 [expanded out v6 style of course], then the code below ends up printing ?::21? instead of ?2001::21?. Please send this report to the request tracker and preferably include a certificate that behaves in that manner. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Bug in IP address parsing?..
On Tue, Sep 08, 2009, Vineet Kumar wrote: Thanks for clarifying that, Stephen. Never use openssl's request racket. When I go to http://rt.openssl.org and use the Quick ticket creation option a the bottom of the page, I get an error: No permission to create tickets in the queue 'OpenSSL-Bugs'. Apparently I need some permission to generate an OpenSSL-Bugs ticket. The lone choice I have from the 'Queue' dropdown is OpenSSL-Bugs, so I am not sure how to submit this ticket. Can someone pl. point out the operator error here? Sorry, Just send an email to r...@openssl.org or openssl-b...@openssl.org Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: [openssl.org #2036] bug report: TLS session resumption not checking for existence of client finished message
Okay, thanks. I have re-opened the original bug against FreeRADIUS so they can comment on whether the problem may be in the patch/additional code. I'll forward their reply and follow up with the author of that code if appropriate. Regards, David -Original Message- From: Stephen Henson via RT [mailto:r...@openssl.org] Sent: Tuesday, September 08, 2009 9:38 PM To: david.good...@g2microsystems.com Cc: openssl-dev@openssl.org Subject: [openssl.org #2036] bug report: TLS session resumption not checking for existence of client finished message [david.good...@g2microsystems.com - Tue Sep 08 09:45:22 2009]: However I was advised that it is not a bug in FreeRADIUS, since FreeRADIUS uses OpenSSL for the required functionality, and it was suggested that I report it to OpenSSL as a bug. I'm not sure this is an OpenSSL bug either. To use EAP IIRC you need to patch OpenSSL and use additional code to support it. I'd suggest contacting the patch/additional code author. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
