RE: Interoperability question
Ok fair enough. I don't *think* it's possible to plug in some arbitrary other crypto, except through the Engine interface. But there are others on the list that actually know something about that, and I can claim only that I know how to spell the word engine. Good luck. Dave +-+-+-+-+-+-+-+-+- Dave McLellan, VMAX Software Engineering, EMC Corporation, 176 South St. Mail Stop 176-V1 1/P-36, Hopkinton, MA 01749 Office:508-249-1257, FAX: 508-497-8027, Mobile: 978-500-2546, dave.mclel...@emc.com +-+-+-+-+-+-+-+-+- -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Thomson, Duncan Sent: Friday, September 13, 2013 9:10 PM To: openssl-users@openssl.org Subject: RE: Interoperability question For reasons I can't go into, it is mandatory that we use Microsoft's "Cryptography Next Generation (CNG)" on Windows. (That's not a decision I have any control over.) If OpenSSL can use CNG for it's crypto functions, then that would probably work for us. Is that possible? Duncan >-Original Message- >From: owner-openssl-us...@openssl.org [mailto:owner-openssl- >us...@openssl.org] On Behalf Of mclellan, dave >Sent: Friday, September 13, 2013 11:48 AM >To: openssl-users@openssl.org >Subject: RE: Interoperability question > >Is there a reason you don't want to use OpenSSL on windows? I'd say >that would be pretty interoperable -- or more appropriately: it would >make your source the same (roughly) for Windows and Linux. > >Humbly suggested... > >+-+-+-+-+-+-+-+-+- >Dave McLellan, VMAX Software Engineering, EMC Corporation, 176 South St. >Mail Stop 176-V1 1/P-36, Hopkinton, MA 01749 >Office: 508-249-1257, Mobile: 978-500-2546, dave.mclel...@emc.com >+-+-+-+-+-+-+-+-+- > > >-Original Message- >From: owner-openssl-us...@openssl.org [mailto:owner-openssl- >us...@openssl.org] On Behalf Of Thomson, Duncan >Sent: Friday, September 13, 2013 1:50 PM >To: openssl-users@openssl.org >Subject: Interoperability question > >Sorry if this is a dumb question, but I did a little searching and >looked at the FAQ, and didn't find an answer, so hope you all won't mind if I >post it here. > >I want to use TLS with an AES cypher to secure client/server >communications for my application. I will be building versions of my >app for both Windows and Linux. On Windows I might use the Schannel API which >in turn I believe will >use CNG for encryption. I want to choose the right libraries to use on Linux >for maximum interoperability. Would openssl be a good choice? > >Thanks in advance for any hints. > >Duncan >___ >___ >OpenSSL Project http://www.openssl.org >User Support Mailing Listopenssl-users@openssl.org >Automated List Manager majord...@openssl.org > >___ >___ >OpenSSL Project http://www.openssl.org >User Support Mailing Listopenssl-users@openssl.org >Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Interoperability question
For reasons I can't go into, it is mandatory that we use Microsoft's "Cryptography Next Generation (CNG)" on Windows. (That's not a decision I have any control over.) If OpenSSL can use CNG for it's crypto functions, then that would probably work for us. Is that possible? Duncan >-Original Message- >From: owner-openssl-us...@openssl.org [mailto:owner-openssl- >us...@openssl.org] On Behalf Of mclellan, dave >Sent: Friday, September 13, 2013 11:48 AM >To: openssl-users@openssl.org >Subject: RE: Interoperability question > >Is there a reason you don't want to use OpenSSL on windows? I'd say that >would be pretty interoperable -- or more appropriately: it would make your >source the same (roughly) for Windows and Linux. > >Humbly suggested... > >+-+-+-+-+-+-+-+-+- >Dave McLellan, VMAX Software Engineering, EMC Corporation, 176 South St. >Mail Stop 176-V1 1/P-36, Hopkinton, MA 01749 >Office: 508-249-1257, Mobile: 978-500-2546, dave.mclel...@emc.com >+-+-+-+-+-+-+-+-+- > > >-Original Message- >From: owner-openssl-us...@openssl.org [mailto:owner-openssl- >us...@openssl.org] On Behalf Of Thomson, Duncan >Sent: Friday, September 13, 2013 1:50 PM >To: openssl-users@openssl.org >Subject: Interoperability question > >Sorry if this is a dumb question, but I did a little searching and looked at >the >FAQ, and didn't find an answer, so hope you all won't mind if I post it here. > >I want to use TLS with an AES cypher to secure client/server communications >for my application. I will be building versions of my app for both Windows and >Linux. On Windows I might use the Schannel API which in turn I believe will >use CNG for encryption. I want to choose the right libraries to use on Linux >for maximum interoperability. Would openssl be a good choice? > >Thanks in advance for any hints. > >Duncan >___ >___ >OpenSSL Project http://www.openssl.org >User Support Mailing Listopenssl-users@openssl.org >Automated List Manager majord...@openssl.org > >___ >___ >OpenSSL Project http://www.openssl.org >User Support Mailing Listopenssl-users@openssl.org >Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Interoperability question
Is there a reason you don't want to use OpenSSL on windows? I'd say that would be pretty interoperable -- or more appropriately: it would make your source the same (roughly) for Windows and Linux. Humbly suggested... +-+-+-+-+-+-+-+-+- Dave McLellan, VMAX Software Engineering, EMC Corporation, 176 South St. Mail Stop 176-V1 1/P-36, Hopkinton, MA 01749 Office: 508-249-1257, Mobile: 978-500-2546, dave.mclel...@emc.com +-+-+-+-+-+-+-+-+- -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Thomson, Duncan Sent: Friday, September 13, 2013 1:50 PM To: openssl-users@openssl.org Subject: Interoperability question Sorry if this is a dumb question, but I did a little searching and looked at the FAQ, and didn't find an answer, so hope you all won't mind if I post it here. I want to use TLS with an AES cypher to secure client/server communications for my application. I will be building versions of my app for both Windows and Linux. On Windows I might use the Schannel API which in turn I believe will use CNG for encryption. I want to choose the right libraries to use on Linux for maximum interoperability. Would openssl be a good choice? Thanks in advance for any hints. Duncan __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: interoperability of C++ libcrypto and Java bouncy castle
On Sun, Feb 28, 2010, ashuahen wrote:
>
> I am using AES_CBC with padding (using PKCS#5 to pad) on C++ side:
>
> AES_set_encrypt_key( keyBuf, 128, &key )
> keyBuf contains key string
> key is the key generated
>
> Block Lenght is 16
>
> AES_cbc_encrypt (ibuf, obuf, lenpad, &key, iv, AES_ENCRYPT)
> ibuf = input data
> obuf = encrypted data
> lenpad = length of data (input data length + pad data length)
> key = key generated by AES_set_encrypt_key
> iv = initialization vector
>
> On java side:
> I am decrypting using following:
>
> SecretKey aesKey = new SecretKeySpec(KeSo.getKey(keyBuffer), "AES");
> keyBuffer: is same as KeyBuf @ C++ side
>
> Cipher cipherDec = Cipher.getInstance("AES/CBC/PKCS5Padding", "BC");
> cipherDec.init(Cipher.DECRYPT_MODE, aesKey, iv);
> cipherDec.doFinal(enc);
> enc: data to be encrypted in byte.
>
> Problem
> ===
>
> I was using libcrypto.0.9.8a and every thing was working fine.
> But as a part of upgrade on Sun SPARC licrypto0.9.8a is changed to
> libcrypto.0.9.8k and things became worst. Encryption is not giving any
> problem but during decryption with the same code I am getting
> BadPaddingException.
>
> Please help me out, this problem has made my life hell.
>
You really shouldn't use the low level ciphers directly as we've advised for
some years:
http://www.openssl.org/docs/crypto/EVP_EncryptInit.html#NOTES
That would for example have taken care of PKCS#5 padding automatically and
allowed the use of external crypto hardware for the operation.
As for your problem. I'd suggest decrypting with the current and older
versions of OpenSSL and seeing if that works.
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
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: Interoperability with Microsoft CA
On Wed, Apr 07, 2004, Steve OBrien wrote: > >What commands have you used on OpenSSL to sign the request? You need the > CA certificate extensions for obvious reasons. > I used openssl ca -sign and CA.pl -sign. > I thought that 0.9.7 would accept the unknown x509 extensions? (as you can > probably tell I am no openssl expert, sorry just trying to figure it out) > Do you have any references for what extensions I need and how to add them? > A sensible set will be added if you use CA.pl -signCA It is possible the certificate request might suggest some extensions too. See if: openssl req -in req.pem -text -noout (where 'req.pem' is the request from MS CA). > >Also how are you trying to import the result back into Microsoft CA? > Well the interesting thing is that I can do a certificate import and see > that in my personal store and import the CA as trusted root but as per M$ > the final step in creating a subordinate CA is to right click the CA in > the Certificate Authority MMC and "install CA certificate." I have tried > the root ca in pks12 format and the signed csr that was generated by this > machine and signed by openssl ca. When I attempt the signed csr cert it > says "The new certificate public key does not match the current > outstanding request. Bad Key (HEX##)" > If you've created the CSR with MS CA then you should just need the certificate and not the private key (which MS CA has stored internally anyway). Try importing the 'newcert.pem' file into MS CA. Failing that convert to DER with: openssl x509 -in newcert.pem -outform DER -out newcert.der and try importing newcert.der with MS CA. 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 List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Interoperability with Microsoft CA
>What commands have you used on OpenSSL to sign the request? You need the CA certificate extensions for obvious reasons. I used openssl ca -sign and CA.pl -sign. I thought that 0.9.7 would accept the unknown x509 extensions? (as you can probably tell I am no openssl expert, sorry just trying to figure it out) Do you have any references for what extensions I need and how to add them? >Also how are you trying to import the result back into Microsoft CA? Well the interesting thing is that I can do a certificate import and see that in my personal store and import the CA as trusted root but as per M$ the final step in creating a subordinate CA is to right click the CA in the Certificate Authority MMC and "install CA certificate." I have tried the root ca in pks12 format and the signed csr that was generated by this machine and signed by openssl ca. When I attempt the signed csr cert it says "The new certificate public key does not match the current outstanding request. Bad Key (HEX##)" TIA, Steve
Re: Interoperability with Microsoft CA
On Wed, Apr 07, 2004, Steve OBrien wrote: > However what my original question was: > I would like to create a subordinate Microsoft CA to my openssl > CA. When doing so in MS land you create a csr, I ship this off to openssl > and sign it, but when it comes back I get errors trying to import it as my > CA. Has anyone had experience doing this. I am not interested in IIS web > server certificates. Thanks > What commands have you used on OpenSSL to sign the request? You need the CA certificate extensions for obvious reasons. Also how are you trying to import the result back into Microsoft CA? 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 List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Interoperability with Microsoft CA
However what my original question was: I would like to create a subordinate Microsoft CA to my openssl CA. When doing so in MS land you create a csr, I ship this off to openssl and sign it, but when it comes back I get errors trying to import it as my CA. Has anyone had experience doing this. I am not interested in IIS web server certificates. Thanks Steve
Re: Interoperability with Microsoft CA
Ron Croonenberg wrote: I tried to get a certificate to work on Windows200 with IIS too. I don't know if this is off topic, but how can I sign a certificate request, created on a windows2000 server. I want to sign the request and create a certificate on a linux machine running openssl then take the certificate and make it work on an the windows machine again. AFAIK when you create the certificate request on the Windows 2000 server it is already signed, with the private key that is left lurking on the server when the CSR is generated. This is how the CSR submitter proves to the issuing CA that it really does have possesion of the private key, that the request itself can be verified with the public key THAT IS PART OF THE REQUEST ITSELF. So what you are asking is the general case and is being done by many people at many places. I don't know of a specific document on this topic, but we certainly were able after reading the OpenSSL documentation and other stuff from the web to figure out how to do this. -- Charles B (Ben) Cranston mailto: [EMAIL PROTECTED] http://www.wam.umd.edu/~zben __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: interoperability
I'm not 100% sure, but I think that you can just get your CA cert signed by verisign, or thawte, or whoever... But you have to have it signed as a CA... Which they're probably loath to do, as each one that you sign is $249 out of their pocket (as they see it) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Nick Temple Sent: Monday, October 29, 2001 04:55 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; modssl-users Subject: Re: interoperability Absolutely. You have to have your root cert signed by their root key, so the chain can be verified. This is pretty much what PKI is all about. Thawte (http://www.thawte.com) used to have information on their website about to do just that. However, I can't seem to find it (things changed when Verisign purchased them :-<). Does anyone have specific URL's about this? Nick *** REPLY SEPARATOR *** On 10/29/2001 at 3:02 PM Juan Carlos Albores Aguilar wrote: >is the following possible?? if so, could you explain me how or point me >documentation about it??. >I create end-user certificates and sign them by my own CA, this kind of >PKI is working on a apache+openssl+modssl system and i would like to make >this certificates to be accepted to other CA's, in somehow, to >interoperate with other certificates or higher, that my CA interoperates >with other CA's. I understan that we're working with X.509 certificates so >the "fields thing" cannot change but i'm talking about when other CA has >the same structure for its certificates and i want to take its >certificates as mine or viceversa, let's say, Verisign certificates, is it >technically possible that its certificates and ours could interoperate?? >or maybe with DoD certificates??. Of course it has to be an agreement and >all those, i repeate, technically. > >Any comments or directions will help so please comment, thanks. > >Juan Carlos Albores Aguilar > > >_ >Do You Yahoo!? >Get your free @yahoo.com address at http://mail.yahoo.com > >__ >Apache Interface to OpenSSL (mod_ssl) www.modssl.org >User Support Mailing List [EMAIL PROTECTED] >Automated List Manager[EMAIL PROTECTED] __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: interoperability
> Juan Carlos Albores Aguilar wrote: > > is the following possible?? if so, could you explain me how or point me > documentation about it??. [...] > certificates and ours could interoperate?? or maybe with DoD certificates??. > Of course it has to be an agreement and all those, i repeate, technically. The easiest way, and most supported by current clients, is to establish a Root CA issuing certificates for sub CAs (hierarchy). It will be possible to recognize and validate sig/certs from the whole chain as the same root is trusted. -- C'you, Massimiliano Pala --o- Massimiliano Pala [OpenCA Project Manager] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.openca.orgTel.: +39 (0)59 270 094 http://openca.sourceforge.netMobile: +39 (0)347 7222 365 S/MIME Cryptographic Signature
Re: interoperability
Absolutely. You have to have your root cert signed by their root key, so the chain can be verified. This is pretty much what PKI is all about. Thawte (http://www.thawte.com) used to have information on their website about to do just that. However, I can't seem to find it (things changed when Verisign purchased them :-<). Does anyone have specific URL's about this? Nick *** REPLY SEPARATOR *** On 10/29/2001 at 3:02 PM Juan Carlos Albores Aguilar wrote: >is the following possible?? if so, could you explain me how or point me >documentation about it??. >I create end-user certificates and sign them by my own CA, this kind of >PKI is working on a apache+openssl+modssl system and i would like to make >this certificates to be accepted to other CA's, in somehow, to >interoperate with other certificates or higher, that my CA interoperates >with other CA's. I understan that we're working with X.509 certificates so >the "fields thing" cannot change but i'm talking about when other CA has >the same structure for its certificates and i want to take its >certificates as mine or viceversa, let's say, Verisign certificates, is it >technically possible that its certificates and ours could interoperate?? >or maybe with DoD certificates??. Of course it has to be an agreement and >all those, i repeate, technically. > >Any comments or directions will help so please comment, thanks. > >Juan Carlos Albores Aguilar > > >_ >Do You Yahoo!? >Get your free @yahoo.com address at http://mail.yahoo.com > >__ >Apache Interface to OpenSSL (mod_ssl) www.modssl.org >User Support Mailing List [EMAIL PROTECTED] >Automated List Manager[EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: interoperability, esp. with a SSLv3(?) server
On Tue, May 16, 2000 at 08:45:08PM -0700, Claus Assmann wrote: > I have a question about the different SSL versions, i.e., which one > should a client use to be interoperable? The specific problem is > with the MTA at mail.stalker.com. I finally got around to do some > more debugging and found out that openssl (starttls) can connect > to it if it uses either SSLv23 with SSL_OP_NO_TLSv1 or SSLv3. > However, in general the client should use SSLv23 without turning > off other protocol versions, correct? So how should I write a client > that can connect to (almost) all servers? > > I'm a bit irritated, because this behavior doesn't match with the > interoperability matrix I posted back in March. Is that MTA running > SSLv3? When connecting with SSLv23_client_method, protocol negotiation starts correctly, i.e. the server sends a ServerHello with version 3.0 in response to the SSL 2.0 format ClientHello with version number 3.1; but then when the client sends ClientKeyExchange with version 3.0 (followed by ChangeCipherSpec and Finished; but the server does not wait for these), an "unexpected message" fatal alert ist returned. This is a server bug (CommuniGate Pro 3.3b6). [Side note: RFC 2487 talks only about "TLS negotiation", and it cannot be inferred from the RFC that using the backward-compatible client hello format is legal, i.e. that servers can be expected to understand it. In discussions about his drafts for a successor to RFC 2487, I've asked Paul Hoffman to clarify this -- e.g. servers MUST be able to understand the backward compatible formats even though they are not required to actually be able to perform SSL 2.0 or SSL 3.0 handshakes, and clients MAY use the backward compatible formats for interoperability with pre-TLS clients --, but that's not what the current RFC says. Of course always using strict TLS will not get you very far, for maximum interoperability you have to use the SSL 2.0 client hello format (in theory TLS 1.0 in SSL 3.0 format would make sense, but SSLeay and old versions of OpenSSL can't handle this format because of bugs in the SSL server implementation). Or connect again and try different SSL/TLS settings if the first handshake attempt fails.] Connected to port 25 of "mail.stalker.com". <<< 00 32 32 30 20 6d 61 69 6c 2e 73 74 61 6c 6b 65 72 220 mail.stalker <<< 10 2e 63 6f 6d 20 45 53 4d 54 50 20 43 6f 6d 6d 75 .com ESMTP Commu <<< 20 6e 69 47 61 74 65 20 50 72 6f 20 33 2e 33 62 36 niGate Pro 3.3b6 <<< 30 0d 0a.. [...] >>> 2a 53 54 41 52 54 54 4c 53 0d 0aSTARTTLS.. <<< f1 32 32 30 20 70 6c 65 61 73 65 20 73 74 61 72 74 220 please start <<< 000101 20 61 20 54 4c 53 20 63 6f 6e 6e 65 63 74 69 6f a TLS connectio <<< 000111 6e 0d 0a n.. >>> 34 80 80 01 03 01 00 57 00 00 00 20 00 00 16 00 00 ..W... . >>> 44 13 00 00 0a 07 00 c0 00 00 66 00 00 07 00 00 05 .f.. >>> 54 00 00 04 05 00 80 03 00 80 01 00 80 08 00 80 00 >>> 64 00 65 00 00 64 00 00 63 00 00 62 00 00 61 00 00 .e..d..c..b..a.. >>> 74 60 00 00 15 00 00 12 00 00 09 06 00 40 00 00 14 `...@... >>> 84 00 00 11 00 00 08 00 00 06 00 00 03 04 00 80 02 >>> 94 00 80 20 7c 49 7c ca 5c 93 5a 84 54 f7 d9 83 73 .. |I|.\.Z.T...s >>> a4 7d 5b de 5b d5 95 4e 30 27 3c ff 3e ea 45 87 09 }[.[..N0'<.>.E.. >>> b4 18 7e.~ <<< 000114 16 03 00 00 4a 02 00 00 46 03 00 39 49 30 fa 30 J...F..9I0.0 <<< 000124 30 30 30 8a 8a d1 59 11 89 d1 f9 69 40 d0 10 0f 000...Yi@... <<< 000134 0f 0f 9c 9b 65 a2 ea fd df 41 41 20 39 25 30 fd eAA 9%0. <<< 000144 44 44 44 44 44 44 44 44 44 44 44 44 44 44 44 44 <<< 000154 44 44 44 44 44 44 44 44 44 44 44 44 00 05 00 ... <<< 000163 16 03 00 02 27 0b 00 02 23 00 02 20 00 02 1d 30 '...#.. ...0 <<< 000173 82 02 19 30 82 01 c3 02 04 1c 92 89 59 30 0d 06 ...0Y0.. <<< 000183 09 2a 86 48 86 f7 0d 01 01 04 05 00 30 81 a9 31 .*.H0..1 <<< 000193 1f 30 1d 06 03 55 04 0a 13 16 53 74 61 6c 6b 65 .0...UStalke <<< 0001a3 72 20 53 6f 66 74 77 61 72 65 2c 20 49 6e 63 2e r Software, Inc. <<< 0001b3 31 0b 30 09 06 03 55 04 06 13 02 55 53 31 0b 30 1.0...UUS1.0 <<< 0001c3 09 06 03 55 04 08 13 02 43 41 31 14 30 12 06 03 ...UCA1.0... <<< 0001d3 55 04 07 13 0b 4d 69 6c 6c 20 56 61 6c 6c 65 79 UMill Valley <<< 0001e3 31 18 30 16 06 03 55 04 0b 13 0f 43 6f 6d 6d 75 1.0...UCommu <<< 0001f3 6e 69 47 61 74 65 20 50 72 6f 31 14 30 12 06 03 niGate Pro1.0... <<< 000203 55 04 03 13 0b 73 74 61 6c 6b 65 72 2e 63 6f 6d Ustalker.com <<< 000213 31 26 30 24 06 09 2a 86 48 86 f7 0d 01 09 01 16 1&0$..*.H... <<< 000223 17 63 67 70 2d 73 75 70 70 6f 72 74 40 73 74 61 .cgp-support@sta <<< 000233 6c 6b 65 72 2e 63 6f 6d 30 1e 17 0d 30
Re: interoperability, esp. with a SSLv3(?) server
On Tue, May 16, 2000 at 08:45:08PM -0700, Claus Assmann wrote:
> I have a question about the different SSL versions, i.e., which one
> should a client use to be interoperable? The specific problem is
> with the MTA at mail.stalker.com. I finally got around to do some
> more debugging and found out that openssl (starttls) can connect
> to it if it uses either SSLv23 with SSL_OP_NO_TLSv1 or SSLv3.
> However, in general the client should use SSLv23 without turning
> off other protocol versions, correct? So how should I write a client
> that can connect to (almost) all servers?
>
> I'm a bit irritated, because this behavior doesn't match with the
> interoperability matrix I posted back in March. Is that MTA running
> SSLv3?
First let's state that RFC2487 (the STARTTLS description) deals with
TLS, not with SSL. If an implementation also supports SSL it is also nice.
I hence feel free to rely on RFC2246 (TLSv1.0).
* Section 7.4.1.2 Client hello
...
client_version
The version of the TLS protocol by which the client wishes to
communicate during this session. This should be the latest
(highest valued) version supported by the client. For this
version of the specification, the version will be 3.1 (See
Appendix E for details about backward compatibility).
...
* Section 7.4.1.3. Server hello
...
server_version
This field will contain the lower of that suggested by the client
in the client hello and the highest supported by the server. For
this version of the specification, the version is 3.1 (See
Appendix E for details about backward compatibility).
...
* Appendix E Backward Compatibility With SSL
...
TLS version 1.0 and SSL 3.0 are very similar; thus, supporting both
is easy. TLS clients who wish to negotiate with SSL 3.0 servers
should send client hello messages using the SSL 3.0 record format and
client hello structure, sending {3, 1} for the version field to note
that they support TLS 1.0. If the server supports only SSL 3.0, it
will respond with an SSL 3.0 server hello; if it supports TLS, with a
TLS server hello. The negotiation then proceeds as appropriate for
the negotiated protocol.
Similarly, a TLS server which wishes to interoperate with SSL 3.0
clients should accept SSL 3.0 client hello messages and respond with
an SSL 3.0 server hello if an SSL 3.0 client hello is received which
has a version field of {3, 0}, denoting that this client does not
support TLS.
...
TLS 1.0 clients that support SSL Version 2.0 servers must send SSL
Version 2.0 client hello messages [SSL2]. TLS servers should accept
either client hello format if they wish to support SSL 2.0 clients on
the same connection port. The only deviations from the Version 2.0
specification are the ability to specify a version with a value of
three and the support for more ciphering types in the CipherSpec.
...
Sorry for citing so long, but I think these sections make things clear.
If CommunigatePro (at mail.stalker.com) does not understand TLSv1
(aka SSLv3.1) client hello messages it violates RFC2246 and hence RFC2487.
Ok, I have just tried to send an email to mail.stalker.com and had the
same problem you had:
May 17 10:11:58 serv01 postfix/qmgr[21907]: A7A6AA82B:
from=<[EMAIL PROTECTED]>, size=813 (queue active)
May 17 10:12:36 serv01 postfix/smtp[19121]: setting up TLS connection
May 17 10:12:37 serv01 postfix/smtp[19121]: verify error:num=20:unable to get local
issuer certificate
May 17 10:12:37 serv01 postfix/smtp[19121]: verify error:num=27:certificate not trusted
May 17 10:12:37 serv01 postfix/smtp[19121]: verify error:num=21:unable to verify the
first certificate
May 17 10:12:37 serv01 postfix/smtp[19121]: SSL3 alert read:fatal:unexpected_message
May 17 10:12:37 serv01 postfix/smtp[19121]: SSL_connect:failed in SSLv3 read finished A
May 17 10:12:37 serv01 postfix/smtp[19121]: SSL_connect error 0
May 17 10:12:37 serv01 postfix/smtp[19121]: 19121:error:140943F2:SSL
routines:SSL3_READ_BYTES:sslv3 alert unexpected message:s3_pkt.c:956:SSL alert number
10:
May 17 10:12:37 serv01 postfix/smtp[19121]: SSL session removed
I have also dumped the connection and it seems that the stalker server
accepts the TLSv1 (SSLv3.1) client hello and then answers with SSLv3
(16 03 00) thus deciding for the SSLv3 (not TLSv1) protocol.
Then (unfortunately :-) certificate information is sent. It would take
a byte-by-byte analysis of the communication or running all of this through
the debugger, both of which my time does not allow in the next days.
See it the Microsoft way: sendmail now offers STARTTLS, my Postfix/TLS
extension is to be integrated into the main package RSN. This should
put enough pressure on stalker to check out their package :-)
Best regards,
Lutz
--
Lutz Jaenicke [EMAIL PROTECTED]
BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/
Lehrstuhl Allgemeine Elektr
Re: Interoperability TLS/SSL
On Mon, Mar 20, 2000, Bodo Moeller wrote: > On Sun, Mar 19, 2000 at 07:51:38PM -0800, Claus Assmann wrote: > > I'm trying to write a server (using OpenSSL) that doesn't use > > patented algorithms, which means I have to restrict my server to > > TLSv1 or SSLv3 (right?), so I would like to use TLSv1 only, but > > then a "default" client (SSL23_method) does not talk to my server. > If you want to allow only TLSv1 in a server (which you actually don't > explicitly have to do if you want to avoid RSA -- configuring the > library with "no-rsa" is enough, as you can see by running "make test" > for the new beta release), you should use SSLv23_[server_]method and > disable the other protocol versions by setting the SSL_OP_NO_SSLv2 > and/or SSL_OP_NO_SSLv3 options. That's the part I was missing. I tried SSLv23_method before (without patented algorithms) and it failed later on because I didn't set that option. Thanks a lot for your long explanation! I should have mentioned that the only part of the table I couldn't understand where that server:TLSv1 and client: SSLv23 did not work together (the rest is obvious), but your explanation makes perfect sense. Now my server seems to work without patented algorithms and with a "default" client. PS: openssl-0.9.5a-beta1 doesn't compile "out-of-the-box" on FreeBSD 3.2, I'll submit an error report (after I tried it one more time...) __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Interoperability TLS/SSL
On Sun, Mar 19, 2000 at 07:51:38PM -0800, Claus Assmann wrote: > I'm trying to write a server (using OpenSSL) that doesn't use > patented algorithms, which means I have to restrict my server to > TLSv1 or SSLv3 (right?), so I would like to use TLSv1 only, but > then a "default" client (SSL23_method) does not talk to my server. If you want to allow only TLSv1 in a server (which you actually don't explicitly have to do if you want to avoid RSA -- configuring the library with "no-rsa" is enough, as you can see by running "make test" for the new beta release), you should use SSLv23_[server_]method and disable the other protocol versions by setting the SSL_OP_NO_SSLv2 and/or SSL_OP_NO_SSLv3 options. The reason is that only SSLv23_[server_]method includes support for backward-compatible client hello messages (SSL 3.0 or TLS 1.0 in SSL 2 format, and TLS 1.0 in SSL 3.0 format; the latter did not work in OpenSSL 0.9.4 or earlier, but should work now). If you use TLSv1_[server_]method, the server will understand only pure TLS and will not be able to communicate with clients that try to be backward-compatible with older protocol versions, which is usually the default for clients even though they may be able to speak TLS. For clients, it's safe to use TLSv1_[client_]method if it's not necessary to be able to interoperate with SSL 2 or SSL 3.0 servers. This is because after the initial message from the client, both parties know which exact procol version to use. SSLv23_method always uses the SSL 2.0 format for client hello messages (except when you're reusing an SSL object for an additional connection -- this is because the object's method is changed when the protocol version is negioated during the initial handshake), so it works only with servers that either are SSL 2 servers or are backward-compatible with the SSL 2 client hello format. There *should* be a way to generate TLS 1.0 client hello messages in the SSL 3.0 record format (the only difference is a version byte in the record header), but this is not possible with OpenSSL clients at the moment -- and it would be a problem because, as noted above, earlier versions of the server were not able to handle this case correctly. > Is there a description which versions of TLS and SSL should be able > to "talk" with each other? Here is my table of testing with openssl > s_server/s_client; please let me know whether this is expected > behaviour, and how I can solve my problem with "normal" clients. > > server tls1ssl3ssl2no_tls1 no_ssl3 no_ssl2 default > client > tls1+ -1 -2 -1 + + + > ssl3-3 + -2 + -4 + + > ssl2-5 -5 + + + -4 + > no_tls1 -6 -7 + + + + + > no_ssl3 -6 -6 + -8 + + + > no_ssl2 -9 -9 -8 + + + + > default -9 -9 + + + + + > > Explanation: +: works, -: fails, the number referst to the list > below, [...] All this should be clear from the above explanation: tls1, ssl3, ssl2 servers accept only that one protocol; ssl2 can communicate with most clients using SSLv23_[client_]method because such clients use the SSL 2 client hello data format. no_tls1, no_ssl3, no_ssl2 servers are compatible with about everything; obviously the handshake cannot succeed if the client speaks *only* the disabled protocol, and the combination of a no_tls1 server and a no_ssl3 client fails because the server has no way to know that the client, which uses the SSL 2 data format to request a TLS 1.0 connection, does not support SSL 3.0. (A more sensible client configuration would be to combine no_tls1 and no_ssl3 instead of just using the latter.) __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Interoperability TLS/SSL
On Sun, Mar 19, 2000 at 07:51:38PM -0800, Claus Assmann wrote: > I'm trying to write a server (using OpenSSL) that doesn't use > patented algorithms, which means I have to restrict my server to > TLSv1 or SSLv3 (right?), so I would like to use TLSv1 only, but > then a "default" client (SSL23_method) does not talk to my server. > > Is there a description which versions of TLS and SSL should be able > to "talk" with each other? Here is my table of testing with openssl > s_server/s_client; please let me know whether this is expected > behaviour, and how I can solve my problem with "normal" clients. [table deleted] As you just found out, SSLv2, SSLv3, and TLSv1 do interoperate in their pure versions. A TLSv1 server will only interporate with TLSv1 clients, that means more or less, other OpenSSL clients. Clients like Netscape only speak SSLv2/3, so you must support at least SSLv3 for real world applications. At least actual versions of Outlook Express (5.0?!, I would have to ask the colleague) support TLSv1, according to my logfiles. Anyway, to make thinks more complicated, clients that do support SSLv2 send an SSLv2 greeting with the option to use a newer (SSLv3/TLSv1) protocol. To understand this greeting, you must at least have SSLv2 enabled, even if you don't want to use it. So probably you want to use SSL23_method with SSL_OP_NO_SSLv2. So much for the technical things. Please don't ask me about the patent issues :-) Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Interoperability TLS/SSL
> I'm trying to write a server (using OpenSSL) that doesn't use > patented algorithms. In all seriousness, why? Is it important that you deploy before September? Your testing matrix was among the most awesome I have ever seen. /r$ __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
