why bad certificate?
I use printf output some debug infomation on server error is below:accepting local ip:(null) tcp port:1081accept return 6 SSL_set_fd(ssl, new_normal_tcp_fd);success SSL_set_mode(ssl, SSL_MODE_AUTO_RETRY); passed SSL_accept failed return 0 253:error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate:s3_pkt.c:1054:SSL alert number 42 on client error is below :bind( slave_normal_tcp_fd, (struct sockaddr *)mine, sizeof(struct sockaddr)); success connecting 192.168.1.203 port 1081 connect master successOpenSSL_add_all_algorithms(); passed SSL_load_error_strings(); passed SSL_CTX_set_cipher_list success SSL_CTX_load_verify_locations(ctx,CA_CERT_FILE_NAME,CA_CERT_FILE_PATH); success SSL_CTX_use_certificate_file(ctx,SLAVE_CERT_FILE, SSL_FILETYPE_PEM); success SSL_CTX_check_private_key success private key agrees with the public key SSL_set_fd(ssl, slave_normal_tcp_fd);success SSL_set_fd passed before SSL_connect a fatal error occurred 165:error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed:s3_clnt.c:888: and my OpenSSL command line:build ca's key and self signed cert openssl genrsa -out cakey.pem 1024 openssl req -new -x509 -key cakey.pem -out cacert.pem -config openssl.cnf - build master's key and csr file 1.build key file openssl genrsa -out master.key 10242.build csr file openssl req -new -key master.key -out master.csr -- build slave's key and csr file openssl genrsa -out slave.key 1024 openssl req -new -key slave.key -out slave.csr-- sign master and slave's cert with use ca's key openssl ca -cert cacert.pem -keyfile cakey.pem -in master.csr -verbose -md md5 openssl ca -cert cacert.pem -keyfile cakey.pem -in slave.csr -verbose -md md5 -- in practice I use master and slave instead of server and client any error with my command line?
make SSL_shutdown work with non-blocking BIOs
Would it be possible to make SSL_shutdown() on non-blocking BIOs, conform
to the documentation and aligned to SSL_read, SSL_write, ...?
http://www.openssl.org/docs/ssl/SSL_shutdown.html
I cooked a tentative patch below, that seems to be working here.
It definitely need double check from someone that has openssl source code
in sight by more than a few minutes (like myself).
The first shutdown will return (modulo other errors) either 0 with
SSL_get_error=WANT_WRITE, or 0 with SSL_get_error=WANT_SHUTDOWN.
The second shutdown will return (modulo other errors) either 0 with
SSL_get_error=WANT_READ, or 1 with SSL_get_error=NONE.
- Davide
---
ssl/s3_lib.c | 18 +-
ssl/ssl.h |1 +
ssl/ssl_lib.c |9 +
3 files changed, 19 insertions(+), 9 deletions(-)
Index: openssl-0.9.8e/ssl/s3_lib.c
===
--- openssl-0.9.8e.orig/ssl/s3_lib.c2007-09-27 23:56:00.0 -0700
+++ openssl-0.9.8e/ssl/s3_lib.c 2007-09-28 15:02:23.0 -0700
@@ -2241,6 +2241,7 @@
int ssl3_shutdown(SSL *s)
{
+ int err;
/* Don't do anything much if we have not done the handshake or
* we don't want to send messages :-) */
@@ -2258,25 +2259,24 @@
#endif
/* our shutdown alert has been sent now, and if it still needs
* to be written, s-s3-alert_dispatch will be true */
+ if (!s-s3-alert_dispatch)
+ return s-shutdown SSL_RECEIVED_SHUTDOWN ? 1: 0;
}
- else if (s-s3-alert_dispatch)
+ if (s-s3-alert_dispatch)
{
/* resend it if not sent */
#if 1
- s-method-ssl_dispatch_alert(s);
+ err = s-method-ssl_dispatch_alert(s);
#endif
}
else if (!(s-shutdown SSL_RECEIVED_SHUTDOWN))
{
/* If we are waiting for a close from our peer, we are closed */
- s-method-ssl_read_bytes(s,0,NULL,0,0);
+ err = s-method-ssl_read_bytes(s,0,NULL,0,0);
}
-
- if ((s-shutdown == (SSL_SENT_SHUTDOWN|SSL_RECEIVED_SHUTDOWN))
- !s-s3-alert_dispatch)
- return(1);
- else
- return(0);
+ if (err 0)
+ return err;
+ return s-shutdown SSL_RECEIVED_SHUTDOWN ? 1: 0;
}
int ssl3_write(SSL *s, const void *buf, int len)
Index: openssl-0.9.8e/ssl/ssl.h
===
--- openssl-0.9.8e.orig/ssl/ssl.h 2007-09-27 23:56:00.0 -0700
+++ openssl-0.9.8e/ssl/ssl.h2007-09-28 12:26:16.0 -0700
@@ -1128,6 +1128,7 @@
#define SSL_ERROR_ZERO_RETURN 6
#define SSL_ERROR_WANT_CONNECT 7
#define SSL_ERROR_WANT_ACCEPT 8
+#define SSL_ERROR_WANT_SHUTDOWN9
#define SSL_CTRL_NEED_TMP_RSA 1
#define SSL_CTRL_SET_TMP_RSA 2
Index: openssl-0.9.8e/ssl/ssl_lib.c
===
--- openssl-0.9.8e.orig/ssl/ssl_lib.c 2007-09-27 23:56:00.0 -0700
+++ openssl-0.9.8e/ssl/ssl_lib.c2007-09-28 12:26:16.0 -0700
@@ -2017,6 +2017,15 @@
}
else
{
+ /*
+* SSL_get_error() may be called with code==0 due to the
+* a partially completed SSL_shutdown() returning 0.
+* This is a state where the shutdown packet has been
+* successfully sent, but we didn't get the peer one
yet.
+*/
+ if ((s-shutdown SSL_SENT_SHUTDOWN)
!s-s3-alert_dispatch
+ (s-shutdown SSL_RECEIVED_SHUTDOWN) == 0)
+ return SSL_ERROR_WANT_SHUTDOWN;
if ((s-shutdown SSL_RECEIVED_SHUTDOWN)
(s-s3-warn_alert == SSL_AD_CLOSE_NOTIFY))
return(SSL_ERROR_ZERO_RETURN);
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
cost of memory allocation in ssl3_accept()
In s3_srvr.c, in ssl3_accept, one finds a BUF_MEM_new() followed by a BUF_MEM_grow(buf,SSL3_RT_MAX_PLAIN_LENGTH). This allocates a 16K buffer per SSL session for use during the handshake. When the handshake is complete, BUF_MEM_free() zeroizes this buffer. As it turns out, this 16K memset() is *the* bottleneck for performance in at least one case I'm interested in -- I can accellerate all the actual crypto operations with a hardware engine, but this memset() eats most of the memory bandwidth of the machine when I get to a few thousand handshakes per second. Looking at other similar code I see buffers of minimal size initially allocated, and then grown as needed. But I'm not sure every place I'd have to touch in the path that uses _this_ buffer to be sure I could do that safely. So, two questions: 1) Does someone more familiar with the code see an immediate and obvious way to avoid this 16K allocation, and thus 16K memset()? 2) Are there constraints I could impose on the handshake such that the full 16K could never actually be required? Thanks! Thor __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: make SSL_shutdown work with non-blocking BIOs
On Sat, Sep 29, 2007 at 01:19:38PM -0700, Davide Libenzi wrote: But that code *never* returns WANT_READ/WANT_WRITE. Non blocking sockets always get SSL_ERROR_SYSCALL. Well, unless the case where they both succeed immediately - but that's like blocking behaviour. Yes, I'm well aware of that. I maintain a great deal of code that uses OpenSSL with non-blocking BIOs, and, yes, when any underlying condition causes the session to not be ready to be shut down, SSL_ERROR_SYSCALL is always the error code returned. No, it's not ideal. Yes, it's what existing application code expects. So it's necessary to be careful about changing this. As far as changes to the existing behaviour, blocking BIOs will never get the new error code (0). And noone could have used the non-blocking BIOs in a sane way, with the current behavior (lack of proper WANT_READ/WANT_WRITE). I'm sorry, but your assertion about WANT_READ/WANT_WRITE is false. In practice, the way it's been for many years is that if you get SSL_ERROR_SYSCALL back, you simply put the socket in your select set for all event types (read/write/exception). Yes, it is a rough spot in the API. Yes, in an ideal world, it would never have worked this way. The problem, as with so much else in OpenSSL, though, is that there's a lot of application code out there by now that knows how the API actually works -- not how it _should_ work, but how it _does_ -- and adding new error returns that weren't possible before will break some of that code. Thor __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: make SSL_shutdown work with non-blocking BIOs
On Sat, 29 Sep 2007, Thor Lancelot Simon wrote:
As far as changes to the existing behaviour, blocking BIOs will never get
the new error code (0). And noone could have used the non-blocking BIOs
in a sane way, with the current behavior
(lack of proper WANT_READ/WANT_WRITE).
I'm sorry, but your assertion about WANT_READ/WANT_WRITE is false. In
practice, the way it's been for many years is that if you get
SSL_ERROR_SYSCALL back, you simply put the socket in your select set for
all event types (read/write/exception). Yes, it is a rough spot in the
API. Yes, in an ideal world, it would never have worked this way. The
problem, as with so much else in OpenSSL, though, is that there's a lot
of application code out there by now that knows how the API actually
works -- not how it _should_ work, but how it _does_ -- and adding
new error returns that weren't possible before will break some of that
code.
Heh? Wait for readwrite? Consider such code:
for (;;) {
err = SSL_shutdown();
code = SSL_get_error(ssl, err);
if (code == SSL_ERROR_SYSCALL) {
select(SSL_get_fd(ssl), RDWR);
continue;
}
...
}
Now consider a typical case, where, just for example, our notify-close is
already gone and we're wating for the peer notify-close. Output buffer are
empty, so the select(RDWR) returns immediately every time you call it.
Same happens in the case where our output buffer are full, we're trying to
send our notify-close, and the peer one is already on our socket buffers.
So, how much CPU is that gonna eat?
It'd be great to see how your code sanely handles SSL_ERROR_SYSCALL with
non-blocking BIOs.
- Davide
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: make SSL_shutdown work with non-blocking BIOs
On Sat, Sep 29, 2007 at 03:11:18PM -0700, Davide Libenzi wrote:
Heh? Wait for readwrite? Consider such code:
for (;;) {
err = SSL_shutdown();
code = SSL_get_error(ssl, err);
if (code == SSL_ERROR_SYSCALL) {
select(SSL_get_fd(ssl), RDWR);
This is not how select() works, but I assume you know that and are
intentionally writing pseudocode. However, what it elides is that,
generally, applications using select() for nonblocking I/O are managing
many sockets at once. In practice, selecting on one of those sockets in
both directions when you only care about one direction is almost zero
cost.
continue;
}
...
}
Now consider a typical case, where, just for example, our notify-close is
already gone and we're wating for the peer notify-close. Output buffer are
empty, so the select(RDWR) returns immediately every time you call it.
Obviously, if you're shutting down, and the socket's returned ready for
write once, you select only for read; the corresponsing condition is true
in the opposite direction.
Yes, it's a stupid API. Yes, it's a nuisance to work around it. But
changing it is _still_ going to break people's code that switches on what
were, previously, the only possible error codes that could be returned
during a shutdown -- which didn't include WANT_READ and WANT_WRITE.
I can easily fix the code _I_ care about to conform to the (better) API
you're proposing. But I don't think that's a particularly good reason to
break other people's code, and pretending that it was impossible to get
the job done isn't tremendously helpful either; there really is a lot of
code out there already that uses non-blocking BIOs despite all their
warts (see my complaints about the need for SSL_select() from several
months ago for another example) and that code really, truly does manage
to shut down sessions without spinning.
Thor
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
RE: make SSL_shutdown work with non-blocking BIOs
Thor Simon wrote:
On Sat, Sep 29, 2007 at 03:11:18PM -0700, Davide Libenzi wrote:
Heh? Wait for readwrite? Consider such code:
for (;;) {
err = SSL_shutdown();
code = SSL_get_error(ssl, err);
if (code == SSL_ERROR_SYSCALL) {
select(SSL_get_fd(ssl), RDWR);
This is not how select() works, but I assume you know that and are
intentionally writing pseudocode. However, what it elides is that,
generally, applications using select() for nonblocking I/O are managing
many sockets at once. In practice, selecting on one of those sockets in
both directions when you only care about one direction is almost zero
cost.
Selecting on one of those sockets repeatedly in a direction for which it is
ready but for which you do not intend to perform an operation has maximal
cost. It will push your CPU consumption right up to 100%.
Obviously, if you're shutting down, and the socket's returned ready for
write once, you select only for read; the corresponsing condition is true
in the opposite direction.
Umm, why? Just becuase you're still shutting down doesn't mean the OpenSSL
library is still trying to perform the same operation. Maybe before it was
trying to send its shutdown but now it's waiting for a response. Maybe
before it was waiting to finish a renegotiation and now it needs to send an
indication to the other side that the connection should be shutdown.
Yes, it's a stupid API. Yes, it's a nuisance to work around it. But
changing it is _still_ going to break people's code that switches on what
were, previously, the only possible error codes that could be returned
during a shutdown -- which didn't include WANT_READ and WANT_WRITE.
Please explain how you work around it. I think you have some hacks that
just happen to work, but no sound way that's guaranteed to work. If you
select for write, you can spin forever. If you don't select for write,
you're simply hoping that OpenSSL didn't actually need to write data.
I can easily fix the code _I_ care about to conform to the (better) API
you're proposing. But I don't think that's a particularly good reason to
break other people's code, and pretending that it was impossible to get
the job done isn't tremendously helpful either; there really is a lot of
code out there already that uses non-blocking BIOs despite all their
warts (see my complaints about the need for SSL_select() from several
months ago for another example) and that code really, truly does manage
to shut down sessions without spinning.
This is one of the many reasons I always use BIO pairs.
DS
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: make SSL_shutdown work with non-blocking BIOs
On Sat, 29 Sep 2007, Thor Lancelot Simon wrote:
On Sat, Sep 29, 2007 at 03:11:18PM -0700, Davide Libenzi wrote:
Heh? Wait for readwrite? Consider such code:
for (;;) {
err = SSL_shutdown();
code = SSL_get_error(ssl, err);
if (code == SSL_ERROR_SYSCALL) {
select(SSL_get_fd(ssl), RDWR);
This is not how select() works, but I assume you know that and are
intentionally writing pseudocode. However, what it elides is that,
generally, applications using select() for nonblocking I/O are managing
many sockets at once. In practice, selecting on one of those sockets in
both directions when you only care about one direction is almost zero
cost.
Yes, I think I know something about select(2), poll(2), and handling many
sockets at a time ;) That was obviously pseudocode.
Handling many sockets at a time does not change the picture though. You'll
permanently exit your I/O scheduler because you get for an event that the
underline API is not waiting for. In the multiple socket example it can be
even worse, since you can have the fd array setup/teardown costs.
Obviously, if you're shutting down, and the socket's returned ready for
write once, you select only for read; the corresponsing condition is true
in the opposite direction.
Yes, it's a stupid API. Yes, it's a nuisance to work around it. But
changing it is _still_ going to break people's code that switches on what
were, previously, the only possible error codes that could be returned
during a shutdown -- which didn't include WANT_READ and WANT_WRITE.
I can easily fix the code _I_ care about to conform to the (better) API
you're proposing. But I don't think that's a particularly good reason to
break other people's code, and pretending that it was impossible to get
the job done isn't tremendously helpful either; there really is a lot of
code out there already that uses non-blocking BIOs despite all their
warts (see my complaints about the need for SSL_select() from several
months ago for another example) and that code really, truly does manage
to shut down sessions without spinning.
I seriously doubt ppl are using SSL_shutdown() with non-blocking BIOs,
together with the current API semantics. Seriously.
- Davide
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: make SSL_shutdown work with non-blocking BIOs
On Sat, Sep 29, 2007 at 03:35:29PM -0700, Davide Libenzi wrote: I seriously doubt ppl are using SSL_shutdown() with non-blocking BIOs, together with the current API semantics. Seriously. Well, how do you suppose they're terminating their SSL sessions? If you look at the archive of this list, you'll see evidence that, in fact, there are users of the non-blocking interface -- pretty much all of whom find it poorly designed and implemented, but, they're users nonetheless. I find the API resulting from your change considerably better. I just am concerned about breaking other people's existing code. And, unfortunately, the text in the RETURN VALUES does actually document how the existing (stupid) API works. On balance maybe it's just best to apply your change. It's hardly up to _me_ whether that happens in the public OpenSSL distribution! It does look correct to me and I've applied it to my local tree, since I control all the code that's linked into. ;-) Thor __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: make SSL_shutdown work with non-blocking BIOs
On Sat, 29 Sep 2007, Thor Lancelot Simon wrote: On Sat, Sep 29, 2007 at 03:35:29PM -0700, Davide Libenzi wrote: I seriously doubt ppl are using SSL_shutdown() with non-blocking BIOs, together with the current API semantics. Seriously. Well, how do you suppose they're terminating their SSL sessions? If you look at the archive of this list, you'll see evidence that, in fact, there are users of the non-blocking interface -- pretty much all of whom find it poorly designed and implemented, but, they're users nonetheless. I find the API resulting from your change considerably better. I just am concerned about breaking other people's existing code. And, unfortunately, the text in the RETURN VALUES does actually document how the existing (stupid) API works. On balance maybe it's just best to apply your change. It's hardly up to _me_ whether that happens in the public OpenSSL distribution! It does look correct to me and I've applied it to my local tree, since I control all the code that's linked into. ;-) It doesn't have to be *my* patch to be applied (I actually suggest a double/triple check over it). Whatever fix you guys come up with, as long as SSL_shutdown() ends up having sane (somehow aligned to SSL_read, SSL_write, etc...) semantics WRT non-blocking BIOs. - Davide __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: make SSL_shutdown work with non-blocking BIOs
I seriously doubt ppl are using SSL_shutdown() with non-blocking BIOs, together with the current API semantics. Seriously. Are you new here? This library has been around for more than a decade. There are *lots* of people using the current API with non-blocking. Seriously. double/triple check over it). Whatever fix you guys come up with, as long as SSL_shutdown() ends up having sane (somehow aligned to SSL_read, SSL_write, etc...) semantics WRT non-blocking BIOs. Nope. Maybe a new shutdown that has your semantics, but do not break existing code. /r$ -- STSM, DataPower Chief Programmer Websphere DataPower SOA Appliances http://www.ibm.com/software/integration/datapower/ __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: make SSL_shutdown work with non-blocking BIOs
On Sat, 29 Sep 2007, Richard Salz wrote: I seriously doubt ppl are using SSL_shutdown() with non-blocking BIOs, together with the current API semantics. Seriously. Are you new here? This library has been around for more than a decade. There are *lots* of people using the current API with non-blocking. Which API are you talking about? SSL_shutdown? If yes, please show how elegantly non-blocking BIOs code can cope with the current SSL_shutdown semantics. - Davide __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: make SSL_shutdown work with non-blocking BIOs
Define elegantly. The current API works. Better is not a reason to change it. /r$ -- STSM, DataPower Chief Programmer Websphere DataPower SOA Appliances http://www.ibm.com/software/integration/datapower/ __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
