Return value of SSL_shutdown()
I'm writing a server with OpenSSL 0.9.8a. When calling SSL_shutdown() to send a close_notify responding to a previous one from the client, a 0 was returned. After some investigation, the reason was found to be the underlying nonblocking BIO was not able to satisfy ssl3_write_pending(). According to the manual page, I expected to get -1. But the code shows that -1 is returned iff the ssl object is not initialized; all other cases except a complete handshake are indicated by 0. Is this intentional? Should I repeat whenever a previous SSL_shutdown() returned 0? How can I know a close_notify has been successfully sent, if I close first, please? Thanks. -- http://www.fastmail.fm - A no graphics, no pop-ups email service __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: RSA_padding_check_PKCS1_type_1:block type is not 01?
Hello, Anyone have any insight into these? Server (my side) is OpenSSL 0.9.8i. My server requests client certificates. The client is likely also Postfix, and thus probably also uses OpenSSL, no idea what version the client is using. The error is not intermittent, every connection from this client encounters the same fate. Is this a configuration issue or a software issue? May 21 22:56:34 hqvsbh1 postfix-edmz/smtpd[923]: SSL_accept error from fb1.bbeyond.nl[82.204.126.25]: -1 May 21 22:56:34 hqvsbh1 postfix-edmz/smtpd[923]: warning: TLS library problem: 923:error:0407006A: rsa routines:RSA_padding_check_PKCS1_type_1: block type is not 01:rsa_pk1.c:100: May 21 22:56:34 hqvsbh1 postfix-edmz/smtpd[923]: warning: TLS library problem: 923:error:04067072: rsa routines:RSA_EAY_PUBLIC_DECRYPT:padding check failed:rsa_eay.c:639: May 21 22:56:34 hqvsbh1 postfix-edmz/smtpd[923]: warning: TLS library problem: 923:error:0D089006: asn1 encoding routines:ASN1_verify:EVP lib:a_verify.c:168: On server side this may happen when server tries to decrypt CertificateVerify packet which is encrypted with client private key. Client should use for this operation PKCS1 padding type 1 (for private key operation). This type of padding sets first byte to 0 and second to 1. Your server after decrypting CertificateVerify packet can not find this values and report error. Some server may try to use other padding type, for example suggested for new application PKCS1 OAEP with is not recognized (for now) with CertificateVerify. Maybe you can trace this with ssldump and send decrypted CertificateVerify packet ? Best regards, -- Marek Marcola [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Client for a server with self-signed ECDSA certificate
Hi ,I was looking for a client which can support my https server which uses ECDSA. I have looked into http://dev.experimentalstuff.com:8082/mozilla/index.html but the link to download the binaries are down. If anyone can provide me a browser with that cipher suite supported so that a handshake with the server can be possible and hence i can test my application.Btw how i test this server with s_client feature of open-ssl . I think we have to provide some option for a self signed certificate. A example of the same will be nice. -- Regards,Puneet BaturaOpen Source Developer
Re: Support for IBM 4764 HSM
Those referenced statements are for specific platforms which do NOT use openSSL for SSL operation with IBM products. Harakiri wrote: --- Steven A. Bade [EMAIL PROTECTED] wrote: the IBM 4758 card. The engine code you refer to was not done by IBM as far as I know, I believe it was done at a university. Yes i know, therefor i ask if anyone already has done something similar. Or even if someone in-the-known can tell me if the 4758 and 4764 are similar in the api so that it would be easy to change the existing 4758 driver... Considering that the core market of the 4764 and the CCA api is at the ATM Pin/Transaction space, why would you expect IBM to do openSSL integration. Easy - because IBM advertise the card not only for PIN transactions but also for SSL Certificates - let me quote http://publib.boulder.ibm.com/infocenter/iseries/v5r4/index.jsp?topic=/rzajc/rzajcco4758.htm QUOTE You can use a Cryptographic Coprocessor along with DCM to generate and store private keys associated with SSL digital certificates. A Cryptographic Coprocessor provides a performance assist enhancement by handling SSL private key processing during SSL session establishment. And as you should be aware of, the most common webservers use openssl libaries for SSL... BTW: I even believe that IBM already programmed such an engine driver (for a specific project maybe), but since IBM is a pretty big company the right hand doesnt know what the left hand does.. =) __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: RSA_padding_check_PKCS1_type_1:block type is not 01?
On Mon, May 22, 2006 at 01:55:48PM +0200, Marek Marcola wrote: May 21 22:56:34 hqvsbh1 postfix-edmz/smtpd[923]: warning: TLS library problem: 923:error:0407006A: rsa routines:RSA_padding_check_PKCS1_type_1: block type is not 01:rsa_pk1.c:100: May 21 22:56:34 hqvsbh1 postfix-edmz/smtpd[923]: warning: TLS library problem: 923:error:04067072: rsa routines:RSA_EAY_PUBLIC_DECRYPT:padding check failed:rsa_eay.c:639: May 21 22:56:34 hqvsbh1 postfix-edmz/smtpd[923]: warning: TLS library problem: 923:error:0D089006: asn1 encoding routines:ASN1_verify:EVP lib:a_verify.c:168: On server side this may happen when server tries to decrypt CertificateVerify packet which is encrypted with client private key. Client should use for this operation PKCS1 padding type 1 (for private key operation). This type of padding sets first byte to 0 and second to 1. Your server after decrypting CertificateVerify packet can not find this values and report error. Some server may try to use other padding type, for example suggested for new application PKCS1 OAEP with is not recognized (for now) with CertificateVerify. Would this also happen when the client's private key does not match the certificate? Why does the handshake fail at this point? Client certificates are not mandatory in my application, so if OpenSSL skipped past the error and acted as though no client credentials were sent, I would prefer that. Is that possible? Maybe you can trace this with ssldump and send decrypted CertificateVerify packet ? Will ssldump help with kEDH? Does the client cert handshake take place before the traffic becomes encrypted? -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: RSA_padding_check_PKCS1_type_1:block type is not 01?
Hello, Would this also happen when the client's private key does not match the certificate? Yes, of course. If client sends to server incompatible certificate (public key) than RSA decryption will succeed (I mean RSA_public_decrypt()) but result will have no sense. Good point :-) With OpenSSL this may be checked with SSL_CTX_check_private_key(). Why does the handshake fail at this point? To retrieve encrypted by RSA_private_encrypt() function data server must remove padding, and this is not possible in this situation. In SSL3 data send by client to server in CertificateVerify packet is 16+20 bytes long, in TLS 12 bytes long. Requesting by server client certificate is equal to request client authentication. So this must succeed. Client certificates are not mandatory in my application, so if OpenSSL skipped past the error and acted as though no client credentials were sent, I would prefer that. Is that possible? You may control requesting from client his certificate with SSL_CTX_set_verify()/SSL_set_verify() with flags SSL_VERIFY_PEER and SSL_VERIFY_FAIL_IF_NO_PEER_CERT. For example you may request from client certificate (SSL_VERIFY_PEER) but not drop connection if none is provided (~SSL_VERIFY_FAIL_IF_NO_PEER_CERT). So after establishing SSL connection you may from application layer decide what client can and what can't do. (But i did not check this myself :-) Will ssldump help with kEDH? I do not know. Does the client cert handshake take place before the traffic becomes encrypted? Yes. Best regards, -- Marek Marcola [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: RSA_padding_check_PKCS1_type_1:block type is not 01?
Hello, If client sends to server incompatible certificate (public key) than RSA decryption will succeed (I mean RSA_public_decrypt()) but result will have no sense. My mistake, I should write: I mean in RSA_public_decrypt(), BN_mod_exp_mont() will succeed (real RSA decryption) but removing padding with RSA_padding_check_PKCS1_type_1() will fail and RSA_public_decrypt() will fail. Best regards, -- Marek Marcola [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: RSA_padding_check_PKCS1_type_1:block type is not 01?
On Mon, May 22, 2006 at 05:26:23PM +0200, Marek Marcola wrote: Hello, Would this also happen when the client's private key does not match the certificate? Yes, of course. If client sends to server incompatible certificate (public key) than RSA decryption will succeed (I mean RSA_public_decrypt()) but result will have no sense. Good point :-) With OpenSSL this may be checked with SSL_CTX_check_private_key(). Why does the handshake fail at this point? To retrieve encrypted by RSA_private_encrypt() function data server must remove padding, and this is not possible in this situation. In SSL3 data send by client to server in CertificateVerify packet is 16+20 bytes long, in TLS 12 bytes long. Requesting by server client certificate is equal to request client authentication. So this must succeed. In my case client authentication is optional, some clients use it, some don't. Client certificates are not mandatory in my application, so if OpenSSL skipped past the error and acted as though no client credentials were sent, I would prefer that. Is that possible? You may control requesting from client his certificate with SSL_CTX_set_verify()/SSL_set_verify() with flags SSL_VERIFY_PEER and SSL_VERIFY_FAIL_IF_NO_PEER_CERT. For example you may request from client certificate (SSL_VERIFY_PEER) but not drop connection if none is provided (~SSL_VERIFY_FAIL_IF_NO_PEER_CERT). So after establishing SSL connection you may from application layer decide what client can and what can't do. (But i did not check this myself :-) I already do all this, but it seems that clients with bad credentials (rather than no credentials) fail. Is it possible to ignore the bad credentials? -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
DTLS
Is there any effort underway to implement Datagram TLS (DTLS) in OpenSSL? DTLS is RFC 4347. Thanks, Hank Cohen __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: DTLS
Hello, Is there any effort underway to implement Datagram TLS (DTLS) in OpenSSL? It is implemented. Best regards, -- Marek Marcola [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: RSA_padding_check_PKCS1_type_1:block type is not 01?
Hello, You may control requesting from client his certificate with SSL_CTX_set_verify()/SSL_set_verify() with flags SSL_VERIFY_PEER and SSL_VERIFY_FAIL_IF_NO_PEER_CERT. For example you may request from client certificate (SSL_VERIFY_PEER) but not drop connection if none is provided (~SSL_VERIFY_FAIL_IF_NO_PEER_CERT). So after establishing SSL connection you may from application layer decide what client can and what can't do. (But i did not check this myself :-) I already do all this, but it seems that clients with bad credentials (rather than no credentials) fail. Is it possible to ignore the bad credentials? I do not see ease method. From source code looks that when server receives CertificateVerify function ssl3_get_cert_verify() is called. When this function returns error - fatal alert is send to client and handshake is terminated. And from logical point of view this is ok. In ssl3_get_cert_verify() there is no callback to change return code. When server sends CertificateRequest to client, client may ignore this or respond with full client authentication. Client authentication requires from client to send to server Certificate packet (with client certificate) and CertificateVerify packet (with some hashed data encrypted with client private key - to check that client has corresponding private key). Server decrypt received CertificateVerify packet with client certificate and check this hashed data against his own. If they are equal - client authentication is verified. If client sends incompatible certificate to server and than uses other private key to encrypt CertificateVerify packet this will fail. But this looks like client fault. Some other application use different way in authentication clients. When client connects, there is no need to authentication and client can do all actions that no required authentication (and for many clients this is enough). But when client wants to do action that requires authentication, server initiates SSL re-handshake with requesting client certificate (and CertificateVerify information). And sorry for my mistake in previous post: In TLS1 length of ClientVerify data is also 16+20 bytes. Length of Finished packet data is 12 bytes. Too many numbers :-) Best regards, -- Marek Marcola [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: RSA_padding_check_PKCS1_type_1:block type is not 01?
On Mon, May 22, 2006 at 07:43:15PM +0200, Marek Marcola wrote: When server sends CertificateRequest to client, client may ignore this or respond with full client authentication. Some other application use different way in authentication clients. When client connects, there is no need to authentication and client can do all actions that no required authentication (and for many clients this is enough). But when client wants to do action that requires authentication, server initiates SSL re-handshake with requesting client certificate (and CertificateVerify information). In my case I don't know who the special clients are, until they send their credentials. Only the clients know in advance that they are special. Is it possible for a client to unilaterally provide credentials without the server explicitly requesting them? If that were possible, I could stop requesting credentials from all clients. I can also operate a separate service port for clients that need to send credentials, but if I can avoid it, and not lose connectivity with misconfigured clients, I'd like to explore that option. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
0.9.8c and zlib, to enable or not to enable?
I see that the padding bug work-around incompatibility issue with zlib is slated to be fixed in 0.9.8c. At that point I see no critical reason to not enable zlib support in our internal 0.9.8c build. RFC 3749 says: However, combining compression with encryption can sometimes reveal information that would not have been revealed without compression: data that is the same length before compression might be a different length after compression, so adversaries that observe the length of the compressed data might be able to derive information about the corresponding uncompressed data. Some symmetric encryption ciphersuites do not hide the length of symmetrically encrypted data at all. Others hide it to some extent, but still do not hide it fully. For example, ciphersuites that use stream cipher encryption without padding do not hide length at all; ciphersuites that use Cipher Block Chaining (CBC) encryption with padding provide some length hiding, depending on how the amount of padding is chosen. Use of TLS compression SHOULD take into account that the length of compressed data may leak more information than the length of the original uncompressed data. So, will compression be on by default in all applications when zlib support is enabled in 0.9.8c, or will applications be expected to specifically turn compression on? If compression is on by default, will applications be able choose to disable it? -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: DTLS
So where's the documentation? I don't find any mention in openssl(1), ssl(3) or crypto(3). Thanks, Hank Cohen -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Marek Marcola Sent: Monday, May 22, 2006 10:01 AM To: openssl-users@openssl.org Subject: Re: DTLS Hello, Is there any effort underway to implement Datagram TLS (DTLS) in OpenSSL? It is implemented. Best regards, -- Marek Marcola [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: RSA_padding_check_PKCS1_type_1:block type is not 01?
Hello, In my case I don't know who the special clients are, until they send their credentials. Only the clients know in advance that they are special. Is it possible for a client to unilaterally provide credentials without the server explicitly requesting them? If that were possible, I could stop requesting credentials from all clients. According to SSL3/TLS1 specification server decides to request client authentication or not. Client authentication is triggered by server by sending to client CertificateRequest handshake packet (in first client connection or in re-handshake (renegotiation)). I can also operate a separate service port for clients that need to send credentials, but if I can avoid it, and not lose connectivity with misconfigured clients, I'd like to explore that option. I think that in this situation only modifying OpenSSL code may help. (workaround against bad configured client) - but this may only complicate things. There are some SSL record layer callbacks in OpenSSL which may be used but this is bad solution :-) Best regards, -- Marek Marcola [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: DTLS
Best regards, So where's the documentation? Look at apps/s_server.c and apps/s_client.c for an example. Best regards, -- Marek Marcola [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: RSA_padding_check_PKCS1_type_1:block type is not 01?
On Mon, May 22, 2006 at 08:47:50PM +0200, Marek Marcola wrote: In my case I don't know who the special clients are, until they send their credentials. Only the clients know in advance that they are special. Is it possible for a client to unilaterally provide credentials without the server explicitly requesting them? If that were possible, I could stop requesting credentials from all clients. According to SSL3/TLS1 specification server decides to request client authentication or not. Client authentication is triggered by server by sending to client CertificateRequest handshake packet (in first client connection or in re-handshake (renegotiation)). I can also operate a separate service port for clients that need to send credentials, but if I can avoid it, and not lose connectivity with misconfigured clients, I'd like to explore that option. I think that in this situation only modifying OpenSSL code may help. (workaround against bad configured client) - but this may only complicate things. There are some SSL record layer callbacks in OpenSSL which may be used but this is bad solution :-) So, faced with clients (whose credentials I don't really need) that get the client authentication wrong, it seems that the best solution for now is to not ask for credentials unless they are always needed, which means a separate service port for clients that authenticate :-( If, in the fullness time, someone has time to make successful decryption of client credentials a non-fatal error, I think that would be a useful feature, provided that it is possible to continue the protocol without verifying the client's signature with any credentials supplied discarded... For now, I will go the multiple ports route... -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Printer-friendly documentation? (Newbie)
Hi there, and hello world! -- I've been using OpenSSL for a long time through Apache and SSH (client/server)... But I would now like to program with it. I would like to use it in my own projects, however, I've been looking through the archive and the website and was unsuccessful at finding a printer-friendly documentation. The documents that are created through compilation of OpenSSL are files.pod and as I'm not familiar with MacOS X (and files.pod) I wonder how I can send it to the printer. Or maybe I should look elsewhere... I wonder if it's the first time a newbie yells: I wanna RTFM!! Well, in my case it's not read but rather print, so i can read at my convenience! Thanks a lot in advance, Simon __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
