RE: Openssl SAN problem
Hi Steve, I'm afraid that's not possible out of security reasons. Regards Andi -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Dr. Stephen Henson Sent: Monday, January 18, 2010 5:09 PM To: openssl-users@openssl.org Subject: Re: Openssl SAN problem On Mon, Jan 18, 2010, Muehlbauer, Andreas wrote: Hi, we are running our own CA with openssl 0.9.8k on linux. We get a CSR-Request containing SAN attributes from a Windows IIS Server: [Version] Signature=$Windows NT$ [NewRequest] Subject = CN=test1 OU=IT, O=Org, L=Location, S=State, C=DE KeySpec = 1 KeyLength = 1024 Exportable = TRUE MachineKeySet = TRUE SMIME = FALSE PrivateKeyArchive = FALSE UserProtected = FALSE UseExistingKeySet = FALSE RequestType = CMC KeyUsage = 0xa0 ProviderName = Microsoft RSA SChannel Cryptographic Provider ProviderType = 12 [EnhancedKeyUsageExtension] OID=1.3.6.1.5.5.7.3.1 [RequestAttributes] SAN=CN=xyzCN=test3 When I try to sign the csr-Request with openssl I get the following error message: Error reading certificate request in xyz.csr 27756:error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong tag:tasn_dec.c:1316: 27756:error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 error:tasn_dec.c:380:Type=X509_REQ_INFO 27756:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:748:Field=req_info, Type=X509_REQ 27756:error:0906700D:PEM routines:PEM_ASN1_read_bio:ASN1 lib:pem_oth.c:83: Signing Requests without SAN-attributes works just fine. Can you post or send me that CSR privately? 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 This communication and any files or attachments transmitted with it may contain information that is copyrighted or confidential and exempt from disclosure under applicable law. It is intended solely for the use of the individual or the entity to which it is addressed. If you are not the intended recipient, you are hereby notified that any use, dissemination, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us at once so that we may take the appropriate action and avoid troubling you further. Thank you for your cooperation. Please contact your local IT staff or email i...@wacker.com if you need assistance. Wacker Chemie AG, Hanns-Seidel-Platz 4, 81737 Muenchen, Germany, Sitz Muenchen, Amtsgericht Muenchen HRB 159705 Vorstand: Rudolf Staudigl (Vorsitzender), Joachim Rauhut, Wilhelm Sittenthaler, Auguste Willems Vorsitzender des Aufsichtsrats: Peter-Alexander Wacker __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Openssl SAN problem
On Tue, Jan 19, 2010, Muehlbauer, Andreas wrote: I'm afraid that's not possible out of security reasons. I'm not sure what security reasons you would have. The CSR only contains the details you put in it and will appear in a public certificate anyway which will be err public. If you don't want the actual contents of the CSR made public can you make one with test data in it? You can send it to me by private email if you wish. Without being able to analyse the encoding of the CSR I can't trace this problem further. 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: trying to understand ECDHE operations
Michael D wrote on Tue, 12 Jan 2010 06:01:23 -0800 (but some of my mail got lost or dropped for some reason and I only later found in mail-archive) (and majordomo 'which' is either broken or deceptive, which didn't help matters!) Dave, I think I have been getting ahead of myself and need to do some more reading. More quick questions, if you don't mind me asking. I have included an answer you gave me months ago regarding Yc. For a 192bit curve, the number of bytes is 50. I imagine one of the bytes is if the point is compressed or uncompressed. (Is that right?) What is the length prefix? Is that what is referred to as PublicValueEncoding in RFC4492? Where can I read about that and how it is set? Thanks for your help, I really appreciate it. I seem to be having trouble explaining effectively. Let's try an example. From s_client -msg per below: TLS 1.0 Handshake [length 00bb], ServerKeyExchange 0c 00 00 b7 03 00 13 31 04 d6 f9 6d 02 15 3a 88 0d da ac ed d7 94 8a ff 6d fa 09 c5 9b ad 39 18 43 24 34 8d 67 7b ca 22 6e 14 fd ab 32 1a 76 19 00 a2 39 8e c8 f8 41 6f b6 00 80 1a a7 e3 92 04 9f 42 db 75 7f 5f 66 7f 43 90 d0 e3 b4 87 e4 9d 27 17 49 1b c2 68 7e eb 20 c3 a2 b0 a3 df 7a fa ab 23 4e 61 b7 8e 11 12 0f 73 74 d0 e9 38 ce 33 ba 07 21 77 0b a5 fe 40 8d a0 51 12 b7 bf ad 0a a3 88 de ce fb a1 a7 73 48 2b 20 48 cd 01 3c f4 5b 14 b7 a2 70 4f 6d 80 07 4a 2d 9e d8 61 37 71 28 1f 55 ec 59 69 ba de 40 87 12 ec d5 06 6e 86 0b ae e6 9e cc f8 ea 27 04 ba dd I interleave the relevant definitions from 4492 and 4346 with (hex)offset: bytes selected from the above. Handshake: HandshakeType msg_type;/* handshake type */ 0: 0c =server_key_exchange uint24 length; /* bytes in message */ 3: 00 00 b7 ServerKeyExchange for case ec_diffie_hellman: ServerECDHParamsparams; Signature signed_params; params: ECParameterscurve_params; ECPoint public; curve_params: ECCurveTypecurve_type; 4: 03 =named_curve (other cases omitted) case named_curve: NamedCurve namedcurve; 5: 00 13 =secp192r1 point: opaque point 1..2^8-1; 7: 31 =length=49decimal + 49bytes beginning at 8: All vectors in TLS begin with a length prefix, see 4.3. So those 49 bytes are the server's point. Per 5.4 it is encoded per ANSI X9.62 and can be uncompressed or compressed; I don't know/have that standard so I just skip 49 bytes. If I ever need to fully understand this I'll read through the code. Apparently here it was uncompressed, since 2*192b = 48 bytes matches almost exactly. Probably first byte 04 means uncompressed. Then Signature has length 39: 00 80 =128decimal followed by 128bytes. (In this example it's an RSA-1k signature because I was that cert i.e. I negotiated ECDHE-RSA-AES128-SHA.) Per 5.7 PublicValueEncoding is used in *Client*KeyExchange to specify a client with an EC cert uses that subjectkey for its (public) point. Otherwise ClientKeyExchange contains the client's ephemeral point, as ECPoint. It doesn't need to specify the curve, because it must share the one specified by the server; and isn't (directly) signed, instead it is included in client's CertificateVerify if used and of course the whole negotiation is verified by Finished. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
FIPS Compilation
Dear Sir or Madam, I am trying to compile openssl-fips-1.1.2.tar.gz on a Windows XP desktop according to the User Guide 1.2 for the FIPS module. The first step is run ms/do_fips.bat. That file does not exist in this tar ball. When I use the do_fips.bat from the OpenSSL-0.9.8j tar ball, it errors. C:\VB\openssl-fips-1.1.2c:\vb\openssl-0.9.8j\ms\do_fips.bat Auto Configuring for X86 Generating x86 for NASM assember Bignum Can't open perl script mo-586.pl: No such file or directory Is there some step in the User Guide that I am missing? If I perform all the steps listed in the FIPS 1.2 User Guide on just the version 0.9.8j, I am successful. except that I have an invalid the FIPS module. Thanks, Ronnie
Re: can TLS be used securely or it is flawed by design not allowing to use it securely
* Kyle Hamilton wrote on Thu, Jan 14, 2010 at 15:50 -0800: On Wed, Jan 13, 2010 at 5:58 AM, Steffen DETTMER wrote: There is currently no way for even an ideal TLS implementation to detect this issue. [...] Yes. Please see SSL_CTX_set_info_callback(3ssl). hum, now I'm confused, I think your last both answers contradict each other... If an application can use e.g. SSL_CTX_set_info_callback to reliably avoid this, I have to read more on what the IETF is working on. If there are webservers `trusting' peers without certificates (allowing pre-injection) what should stop people to ignore whatever extension as well... What SSL_CTX_set_info_callback() does is tell you *when* a renegotiation occurs. It doesn't tell you what happened before. (assuming, that a peers identity should not change within a session - but as discussed later in this mail this could be wrong?): In the implementation of this callback, shouldn't the HTTP server in first call store the peer identity (maybe the DN value of the certificate) and abort when in a second or subsequent call suddenly another value of DN is found within the same HTTP session? Does the standard require to allow / to support chaning a DN during one TLS session? (of course, most HTTPS services don't use client certificates, so it won't help in practice) Someone could expect whenever a browers window or `tab' is operating in some extended validation mode. As I think I mentioned, nobody ever actually mapped out the precise semantics of how the green bar is supposed to work. That is EV's biggest Achilles's Heel... nobody knows what it means, the same way nobody knew what the lock meant. I think, most people take security in a very pragmatic way. It should not cost additional efforts, but the investable efforts effectively limit the reachable security. OT: I personally would wish to be able to put a browser tab or better even a browser instance into some `secured' mode (for online banking HTTPS but not for myspace HTTPS). In this mode, flash would not work, no plug-ins installed and I would be warned when the DN of a certificate of a web page changes (now, I'm warned only if CN does not match DNS name, but I would like to be informed: www.xyz.com now is DN=XYZ Ltd. UK but last time it was DN=XYZ Inc. US or so). Probably there are many more nice security features that could be turned on. This would not prevent the twitter attack but maybe could make online banking attacks more expensive. With firefox, this is possible using different profiles with MOZ_NO_REMOTE but this breaks other things (today, systems seem to rely on a single running browser instance). or something like `ssh -X safeu...@localhost firefox' :) Ohh, and this would catch passwords `system modal' just like ssh-add can do. It is too bad when half of the password reaches some online chat tool just because the session manager opens tabs that were open at the point of a previous crash, giving them focus for a short time... I really really dislike firefox asking for master password while continuing in the background with optional focus change... sorry all of this is off-topic. You cannot call an application that uses SSL/TLS secure any more than you can call a network that has a firewall secure. yes, this is very true, but I'm afraid many people assume that this `any more' is quite a lot. For example, nowadays simple packet filters alone are called firewalls (some years ago, packet filters were just a less important small layer, mostly set up because it costs almost nothing, but security was applied by a combination of proxies understanding their protocol and filtering based on its content, for example with virus-checking, and TCP wrappers etc). I think for many a `SSL secured' label on a webpage means that the running application (lets say a online banking web app) is secured. I think this is a server (configuration) bug but no TLS bug. How can someone assume it would be safe for preinjection when accepting anonymous connections? ...because they didn't realize that the prior session isn't cryptographically bound to the new session, it's a complete wiping of the slate. It is certainly an application-design issue (defense in depth is not just a buzzword), but it's also a TLS protocol issue as one of the guarantees that the protocol attempted to provide was violated. Isn't TLS requiring to use client certificates to be able to guarantee that the client remains the same? If TLS is not using client certificates, doesn't this mean that anyone is accepted? (yes, in the Twitter case the application design and using Basic Auth surely isn't highly secured) It's also strange that SSL + BasicAuth seems to be so common. For many web services, users register and receive some confirmation mail with a password or alike. Why isn't it standard practice that users get a client certificate? Of
Query about Meinberg NTPV4 4.2.4p7 client compatibility with other thirdparty NTPV4 servers
Hi All, I am developing an NTPV4 client/server as per NTPV4 standards. We tried our client application with 'Meinberg NTPV4 4.2.4p7' server and found it to be working fine with MD5 hashing. But viz.. is not working (our server application is not working with the 'Meinberg NTPV4 4.2.4p7' client. ) Inference: 'Meinberg NTPV4 4.2.4p7' client sends the ASSOC request and receive the ASSOC response from our server. But the Meinberg client again sends the ASSOC request to our server instead of sending the CERT request. The logic for generating the MAC is same for our client as well as server. The data in the ASSOC response is also same as that of Meinberg Server's response except the time and KeyID. But not sure why it is not working? Please let me know if any one of you has any insight about this issue. Thanks Mathews Important notice: This e-mail and any attachment there to contains corporate proprietary information. If you have received it by mistake, please notify us immediately by reply e-mail and delete this e-mail and its attachments from your system. Thank You. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL Ca
Thankyou all...Your comments helped a lot and I have managed to get my CA running perfectly.. Thanks! Anton 2010/1/12 Patrick Patterson ppatter...@carillon.ca Ok - several things: 1: Does the certificate contain both an email address, and EKU of emailProtection? 2: Did you import the CA certificate chain before trying to import the certificate? 3: I presume this certificate is so that you can perform S/MIME encryption - do you have the correct values in Key Usage? ( keyEncipherment, dataEncipherment) What does your openssl.cnf section say for the type of certificate generated? What does your CA Certificate look like? If you want help setting up a CA that just works for most of these different kinds of certificates, you can grab our OpenSSL CA Setup guide (http://www.carillon.ca/library/openssl_testca_howto_1.2.pdf) - it's for the more complex environment of CertiPath/US Federal Bridge interoperability, but it gives you a good idea of what is required for the various profiles of certificates to have them work in various use cases (one size most definitely does NOT fit all, and the stock openssl.cnf isn't sufficient :) Have fun! Patrick. On January 12, 2010 08:23:18 am Anton Xuereb wrote: The Client im trying to import the public key into is Thunderbird 3 on linux. The client on windows is MS outlook with winpgp installed for pgp encryption. The problem is being presented with thunderbird at the moment as I'm trying to import the public key in order to be able to send encrypted emails to the windows machine. Thanks, Anton 2010/1/12 Mounir IDRASSI mounir.idra...@idrix.net Hi, What mail client are you using under Windows? Each mail client has its own storage for private keys (Thunderbird uses local NSS key storage, Outlook uses CSP and IE certificate store). So, since you generated the key outside the scope of the mail client, you will certainly have to create a PKCS#12 file (called also PFX under Windows) containing your private key and its signed certificate and then import this file into your mail client's key storage (for Outlook, you'll have to install the PFX by double-clicking on it). So, everything depends on your mail client and how it will access your private key. Cheers, -- Mounir IDRASSI IDRIX http://www.idrix.fr On 1/12/2010 12:35 PM, Anton Xuereb wrote: Hi, I'm trying to create a private CA with openssl for my enterprise. I have generated the CA private key and certificate. I have created a key pair and a certificate signing request from a windows pc using kleopatra (key management utility that comes with winpgp). I signed the request with the CA's key and sent the signed certificate to the windows pc and imported the certificate. I exported the public key which I sent to my laptop. I imported the certificate of my CA into my mail client and trusted it. I then imported the public key as exported from the windows pc. It is imported but instead of being put into the People category it's sent in the Others section as it apparently does not fit in any of the other categories. I am therefore unable to send encrypted mail to the windows pc using it's public key as my client will not use it to encrypt. The following are the commands I used in order to get to this point: In order to generate the private key and ca certificate: # openssl req -config openssl.my.cnf -new -x509 -extensions v3_ca -keyout private/myca.key -out certs/myca.crt -days 1825 I converted the request from DER to PEM format using: openssl req -in datareq.p10 -inform der -out datareq.csr In order to sign the request: # openssl ca -config openssl.my.cnf -policy policy_anything -in datareq.csr I'm at a loss at the moment so any help would be appreciated. Thanks , Anton -- -- Mounir IDRASSI IDRIX http://www.idrix.fr __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org -- Patrick Patterson President and Chief PKI Architect, Carillon Information Security Inc. http://www.carillon.ca __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Query about Meinberg NTPV4 4.2.4p7 client compatibility with other thirdparty NTPV4 servers
On Tue, Jan 19, 2010 at 07:43:34PM +0530, Emmanuel, Mathews IN BLR SISL wrote: Inference: 'Meinberg NTPV4 4.2.4p7' client sends the ASSOC request and receive the ASSOC response from our server. But the Meinberg client again sends the ASSOC request to our server instead of sending the CERT request. This is the OpenSSL users list. It seems to me that question belongs on an NTP developer list. If you have a question about how to construct message digests, please ask that question, directly. A common pitfall, which I am guessing you did not fall into, but just in case: Make sure you don't use strlen() or strcpy(), ... with raw binary message digests, as these will contain null bytes, with a probability of 1/256 per byte. The odds of an MD5 digest containing no null bytes are: (255/256)^16 ~ 93.9% For SHA1 these drop to: (255/256)^20 ~ 92.5% perhaps your MD5 test was lucky, and SHA1 test was unlucky? If you are actually computing and copying the hash value correctly, the rest is material for an NTP protocol discussion list. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: FIPS Compilation
On Mon, Jan 18, 2010, R Kahn wrote: Dear Sir or Madam, I am trying to compile openssl-fips-1.1.2.tar.gz on a Windows XP desktop according to the User Guide 1.2 for the FIPS module. The first step is run ms/do_fips.bat. Wrong version. You need the 1.2 version of the tarball from: http://www.openssl.org/source/openssl-fips-1.2.tar.gz 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: impact of client certificates to re-negotiation attack
* Kyle Hamilton wrote on Thu, Jan 14, 2010 at 12:03 -0800: * Steffen asked... ...on this level [thanks a lot again for all the clarifications: authentication levels, authentication-agnostic, URI-dependent certificates, bugfix because missed intention, MITM tricks twitter to decrypt and disclose, epoch 1 to detect renegotiation, and GnuTLS] There's an implementation which uses OpenPGP keys/assertions, called GnuTLS. [...stores client cert hashes...] (and no, this doesn't count as 'design a cryptosystem'. What you're proposing is essentially to allow the client to set its own public key, and thus trust anchor, upon correct authentication. public/private keypairs are first-order identities; the reason CAs exist is because it's impossible to know who claims that any given keypair belongs to him without external intervention, and CAs are *supposed* to strongly bind [using their own private key] the appropriate details of the individual who did present the public key for certification. However, authenticating to the Server with a username/password, and submitting a public key, is more than enough to be able to issue a certificate related to that username.) ahh ok. This isn't common because not so easy-to-use, yes? Using (real) CAs could have disadvantages when it comes to privacy or when someone wants to use pseudonyms, I think. Oh dear gods yes. I've been trying to get people to see that for years. Thank you. (As I think I mentioned, Wes Kussmaul is working on a project that provides a different approach to the issue, but we're both hampered by the lack of decent client certificate generation UIs.) Even with a UI avialable I could imagine that it could be difficult to get a wide acceptance; I think many know the term SSL and associate it 1:1 with internet security. Difficult topic. Good to know that experts (like you) are working on it. You, since your signature says that you work for a payment solutions provider, would not normally be one (in my eyes) to raise the privacy concern -- but this suggests that you are in the EU, where regulations are more strict. There are several privacy concerns in payment systems. For example, error messages may not be transmitted to protect card holder privacy (sometimes making it difficult to track down some issues), laws and requirement specs are about how to store data (like PAN of credit cards). The German electronic purse (pre-paid card) is even able to do anonymous payment transactions (requiring a card not bound to any account; such cards are rarely seen but exist). Whatever I write here is my personal opinion only and I'm not a security expert etc #include disclaimers/full_super_safe.h... Yes, you helped me a lot, it was great lecture. Thank you very much that you again provided me free lessons with so many information!! You are most welcome. I think that this knowledge, above all else, *must* be free, if people are to be able to learn how to protect themselves and their information. Also, your comments here have spurred me into thinking about different parts of the problem... for example, a user cannot be a CA, under X.509. Ohh why not? Forbidden by rfc5280 or so? I though setting the needed basic constraint cA=TRUE would do the job? (beside that I don't know any public CA that would ever certify such a certificate because typically in the web then I would inherit the trust :-) which maybe just shows that this chains might be bad in general - just because I trust a CA this does not neccesarily mean I trust anyone who was able to authenticate itself to this CA). In theory, wouldn't even a self-signed user certificate be possible (e.g. when the server maintains a user-password-certhash data base), like you mentioned in GnuTLS (unless I missunderstood)? A self-signed-only PKI? However, there is a different certificate profile which allows users to issue certificates based on their own credentials, called the proxy certificate profile (defined in RFC 3820 -- which I wish they hadn't numbered it as, since it's so easy to lysdexiate that to RFC 3280 -- the predecessor to the current PKIX, RFC5280.) It might be useful to issue a user a certificate, and then allow authentication using proxy certificates issued by that user's certificate, thus reducing the number of times the private key is actually used -- allowing it to be stored offline, for example, while proxy certificates issued by it are online and used. ohh yes, and my USB class 3/4 smart card reader's display could display the proxyPolicy in an appropriate (for me verifyable) form, I could decide to enter my PIN or to cancel. I could generate a 1yr valid myspace cert stored on my laptop and a 10 minutes valid one for my banking account or even limited to a single transaction (including amount and destination account name in the proxyPolicy to allow me to verify on a trusted class 3/4 device). cool. Or having a cell phone application.
Recommandation related to tools to be used with OpenSSL
I have the following scenario: i need an application that will do the following: 1. there is an input folder. In this folder, files will be copied/downloaded. 2. An application/script will periodically query this folder (auto-detection is also accepted). 3. if a new file is detected, the application will execute openssl smime -encrypt | openssl smime -sign commands on the file. 4. the output files (encrypted file and encrypted-signed files) will be dropped in an Output folder. The reverse operation is also expected: 1. an input folder will be queried periodically for new encrypted-signed files (auto-detection is also accepted). 2. if a new file is found, the following commands are applied: openssl smime -verify | openssl smime -decrypt and the following actions are perfromed: 2.1. The Signature is verified. The validation process will drop to an external file (txt, csv) the result of the validation (pass/failed). 2.2 The Encrypted file is decrypted in another folder. My question is actually a request for a recommandation related to an easy development tool (programming language, scripting) that is able to perform these operations, including the injection of openssl commands. Thank you, Victor -- View this message in context: http://old.nabble.com/Recommandation-related-to-tools-to-be-used-with-OpenSSL-tp27227875p27227875.html Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
utf8string vs printablestring mismatch in certificate checking
We are having trouble using openssl's certificate checking to validate certain certificates where certificates in the chain are inconsistent in their choice of string encoding. Using e.g. openssl-0.9.8e-12.el5, the connection in the accompanying certificate chain (intermediate cert and final cert only attached) will never be made by openssl. I think that this is because the intermediate cert has issuer Government of Korea (utf8, type 12) but the root cert is subject Government of Korea (printable, type 19), so it doesn't see this intermediate cert as signed by this issuing cert due to the names not matching (although they do match semantically, as it were); openssl looks for the wrong hash value in the CAdir and, even if I fake up a symlink in the CAdir to the right root cert, it doesn't use it. Internet Explorer accepts the same certificate chain, and presumably that is how it is in use in the field (Korea is known for being quite IE-centric, or at least it used to be). I have seen this problem on another private/governmental CA before but the problem was fixed before I got around to looking for solutions. Have I diagnosed the problem correctly? Is this behaviour by openssl correct or incorrect, likely to change, or is it possible to make it work at the application level? (CC replies to me as I am not on the list) -- Colin Phipps c...@netcraft.com Issuer: C=KR, O=Government of Korea, OU=GPKI, CN=GPKIRootCA Not Before: Mar 15 06:00:04 2007 GMT Not After : Mar 15 06:00:04 2017 GMT Subject: C=KR, O=Government of Korea, OU=GPKI, CN=GPKIRootCA -BEGIN CERTIFICATE- MIIDijCCAnKgAwIBAgIQRfjg5AHFPnHmvXFtl5xBIzANBgkqhkiG9w0BAQUFADBP MQswCQYDVQQGEwJLUjEcMBoGA1UEChMTR292ZXJubWVudCBvZiBLb3JlYTENMAsG A1UECxMER1BLSTETMBEGA1UEAxMKR1BLSVJvb3RDQTAeFw0wNzAzMTUwNjAwMDRa Fw0xNzAzMTUwNjAwMDRaME8xCzAJBgNVBAYTAktSMRwwGgYDVQQKExNHb3Zlcm5t ZW50IG9mIEtvcmVhMQ0wCwYDVQQLEwRHUEtJMRMwEQYDVQQDEwpHUEtJUm9vdENB MIIBITANBgkqhkiG9w0BAQEFAAOCAQ4AMIIBCQKCAQBaK0EVm9t2JgHwVHILhxMf oNA/lqoNszSB3khan/NwWsLxOp4E8E6UeZfh9LUUTNdvxIsYt9wSKx0Km+4gDFuP //mvgp6YRtA9XSjzlxbBXOVWv0SkAKF6y5t6W9zU7fvyoAJnAB5E5YoB3KWjTv7W DGfKSbnw0KD5TR8D04bvDYV1TfPt+81qZgRX9FebrGaKT8KoT3GJCd1MAN+Wu9WQ CrS2am3Gv9OZKf9i8BDaRawJcguCEOgVqItf4qJaeR7CZ/3pRFcLA9AhFVGwAPOP beIj8Ekh2W3PYj3s6/0okgE/eqNyfOvzruf4CuxurXqbVckwS5y2YUZrWBr+n0gd AgMBAAGjYzBhMB8GA1UdIwQYMBaAFBZnMvRoXmgxR9vt7M5hLpokRsR9MB0GA1Ud DgQWBBQWZzL0aF5oMUfb7ezOYS6aJEbEfTAOBgNVHQ8BAf8EBAMCAa4wDwYDVR0T AQH/BAUwAwEB/zANBgkqhkiG9w0BAQUFAAOCAQEANWNSxmAYHLfCwVpYAuwH1aGQ k/yAR9BSeKuF+HbTuLAYMqC2kGgTZj1vr47c9qPEzjlfr+0KZuB8EcgMy54fOCmK i97IYy7HtNLONpGU4E+EkraqIqj9MaczSMlb9hPYFhbrHz+lTgaTOtkGZTCW+o0G 26Ea9Cv6D2jwwSt8nQXXCUI70i+RkPwOazhbsnWpV5xXZPWYIKT/1DAE5M4fkMkv wd9aVrjLqqq0v+u49yJKTcE19GW9eLxveBtWOoHoDfXCpRcw041Xd8ulwUyxMN00 uKuSCiICNov2bPdhuQjuMK0aqETxLjLsg6JISDpnX+lvGxczCCrBycNnmg6FZw== -END CERTIFICATE- Issuer: C=KR, O=Government of Korea, OU=GPKI, CN=GPKIRootCA Not Before: Jun 9 14:09:21 2008 GMT Not After : Jun 9 14:09:21 2018 GMT Subject: C=KR, O=Government of Korea, OU=GPKI, CN=CA134040001 -BEGIN CERTIFICATE- MIIEXjCCA0agAwIBAgIQR/72AAIHhtgBkjX/nkogAjANBgkqhkiG9w0BAQUFADBP MQswCQYDVQQGEwJLUjEcMBoGA1UECgwTR292ZXJubWVudCBvZiBLb3JlYTENMAsG A1UECwwER1BLSTETMBEGA1UEAwwKR1BLSVJvb3RDQTAeFw0wODA2MDkxNDA5MjFa Fw0xODA2MDkxNDA5MjFaMFAxCzAJBgNVBAYTAktSMRwwGgYDVQQKDBNHb3Zlcm5t ZW50IG9mIEtvcmVhMQ0wCwYDVQQLDARHUEtJMRQwEgYDVQQDDAtDQTEzNDA0MDAw MTCCASEwDQYJKoZIhvcNAQEBBQADggEOADCCAQkCggEAZvDlMT1PwNhEkeB5Wvvy CrQXf10ah2jWNDq3A86IEHOVRB3sNoABgkCHue70jIa/EI9PRpdoouPYdR+DJPkF S9QLizlgkrPCNQhJqr7vuXQd/JV2OFhKhsrlIrKZaB1FU0ndJmzezZUZZxBfsBz6 LAjRZn4EVPPqQY+DR7fSrgh8h6yGPMhMtV8aADTpMkLmnfSjYJKsY4NTYheBsXQ7 kr2d3CK5a7Sn3Nze4TvC05DyctpTWPJNyFOx8Ahyi0dVg77mNNx4uPXQhlip4n4p V4ibLlVw+O9E9/7lUDG31yH/wgSl4ukwcQjHHXI2dadvP2M63tjdHXfZVHBHY3Ig KwIDAQABo4IBNDCCATAwHwYDVR0jBBgwFoAUFmcy9GheaDFH2+3szmEumiRGxH0w HQYDVR0OBBYEFPpyBAOZ/erbfFDdvuVypNJ3JRXIMA4GA1UdDwEB/wQEAwIBBjBP BgNVHSAESDBGMAwGCiqDGoaNIQUDAQMwDAYKKoMaho0hBQMBATAMBgoqgxqGjSEF AwEHMAwGCiqDGoaNIQUDAQkwDAYKKoMaho0hBQMBBTASBgNVHRMBAf8ECDAGAQH/ AgEAMHkGA1UdHwRyMHAwbqBsoGqGaGxkYXA6Ly9jZW4uZGlyLmdvLmtyOjM4OS9j bj1HUEtJUm9vdENBLG91PUdQS0ksbz1Hb3Zlcm5tZW50IG9mIEtvcmVhLGM9S1I/ YXV0aG9yaXR5UmV2b2NhdGlvbmxpc3Q7YmluYXJ5MA0GCSqGSIb3DQEBBQUAA4IB AQAhagazxtMY+p+i1F/OyJJ0kwZU8PrKISJUZMpBxMaZpfCzUWSnaO9Ha6SPnqm8 gE71ZJV+KUj6ll6YL3VExaGU2YPpNUzbo4mFuTP5QBo+d18sEZAIsKPAG2ZXw1wU Bx51jduMBWGYo43JFS+XPlrxrYULPobprudrqTt+EffG++hey18VBk/mPubyovFl MZ74esV96IenJvGxMNhsS+U+RIE1QoLDscJrlenmjctbowNZ8pq91MJw6V8OG0w9 ELVQMt98uidzU2fzF4W0XxHiIlZBtp6imOZxQ+xtCiJd0/S/jpEoHBU9ZEJrBRol RMdvf5Oh2qTLeowZU17RtC8T -END CERTIFICATE-
Re: utf8string vs printablestring mismatch in certificate checking
On Tue, Jan 19, 2010, Colin Phipps wrote: We are having trouble using openssl's certificate checking to validate certain certificates where certificates in the chain are inconsistent in their choice of string encoding. Using e.g. openssl-0.9.8e-12.el5, the connection in the accompanying certificate chain (intermediate cert and final cert only attached) will never be made by openssl. I think that this is because the intermediate cert has issuer Government of Korea (utf8, type 12) but the root cert is subject Government of Korea (printable, type 19), so it doesn't see this intermediate cert as signed by this issuing cert due to the names not matching (although they do match semantically, as it were); openssl looks for the wrong hash value in the CAdir and, even if I fake up a symlink in the CAdir to the right root cert, it doesn't use it. Internet Explorer accepts the same certificate chain, and presumably that is how it is in use in the field (Korea is known for being quite IE-centric, or at least it used to be). I have seen this problem on another private/governmental CA before but the problem was fixed before I got around to looking for solutions. Have I diagnosed the problem correctly? Is this behaviour by openssl correct or incorrect, likely to change, or is it possible to make it work at the application level? Changing the encoding does violate a few standards including RFC3280 and RFC5280 but a few errant CAs exist which do it. Your analysis of that case is correct. If you use the command: openssl x509 -in mogaha.pem -subject -issuer -nameopt multiline,show_type -noout -subject_hash -issuer_hash You can clearly see the result: subject= countryName = PRINTABLESTRING:KR organizationName = PRINTABLESTRING:Government of Korea organizationalUnitName= PRINTABLESTRING:GPKI commonName= PRINTABLESTRING:GPKIRootCA issuer= countryName = PRINTABLESTRING:KR organizationName = PRINTABLESTRING:Government of Korea organizationalUnitName= PRINTABLESTRING:GPKI commonName= PRINTABLESTRING:GPKIRootCA 20e6f02d 20e6f02d Note the two hash values are the same. Whereas for mogaha_int.pem you get: subject= countryName = PRINTABLESTRING:KR organizationName = UTF8STRING:Government of Korea organizationalUnitName= UTF8STRING:GPKI commonName= UTF8STRING:CA134040001 issuer= countryName = PRINTABLESTRING:KR organizationName = UTF8STRING:Government of Korea organizationalUnitName= UTF8STRING:GPKI commonName= UTF8STRING:GPKIRootCA 610e5e7b 449b326d You can see here that the string types differ and the second hash value (issuer) doesn't match those for mogaha.pem. If you tried getting those hash values with with OpenSSL 1.0.0 or later using: openssl x509 -in mogaha.pem -subject_hash -issuer_hash -noout you get this: mogaha.pem: 11e07c09 11e07c09 mogaga_int.pem aac725e5 11e07c09 Here you'll see that now the issuer hash matches because 1.0.0 uses a different algorithm for computing hashes which relies on a form of canonical encoding. So the best I can suggest is using 1.0.0 which is currently in beta. For compatibility reasons we can't backport the modified algorithm to 0.9.8. I think MSIE uses SKID/AKID to build chains if the extensions are present avoiding DN matching altogether though that can introduce its own problems. 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: can TLS be used securely or it is flawed by design not allowing to use it securely
On Tue, Jan 19, 2010 at 6:19 AM, Steffen DETTMER steffen.dett...@ingenico.com wrote: * Kyle Hamilton wrote on Thu, Jan 14, 2010 at 15:50 -0800: On Wed, Jan 13, 2010 at 5:58 AM, Steffen DETTMER wrote: There is currently no way for even an ideal TLS implementation to detect this issue. [...] Yes. Please see SSL_CTX_set_info_callback(3ssl). hum, now I'm confused, I think your last both answers contradict each other... If an application can use e.g. SSL_CTX_set_info_callback to reliably avoid this, I have to read more on what the IETF is working on. If there are webservers `trusting' peers without certificates (allowing pre-injection) what should stop people to ignore whatever extension as well... What SSL_CTX_set_info_callback() does is tell you *when* a renegotiation occurs. It doesn't tell you what happened before. (assuming, that a peers identity should not change within a session - but as discussed later in this mail this could be wrong?): In the implementation of this callback, shouldn't the HTTP server in first call store the peer identity (maybe the DN value of the certificate) and abort when in a second or subsequent call suddenly another value of DN is found within the same HTTP session? Does the standard require to allow / to support chaning a DN during one TLS session? (of course, most HTTPS services don't use client certificates, so it won't help in practice) If there's a certificate DN or Issuer change (even from null to something non-null), I agree that in many/most circumstances it's reasonable to abort the connection. It doesn't necessarily follow, though, that because it's the reasonable thing in most circumstances that it's the correct thing to do in all circumstances. (Imagine an ATM with a TLS-encrypted serial line or other link back to the central processing house. It has its own certificate -- the processing house doesn't want to accept connections that it can't authenticate -- so it builds that TLS channel with mutual authentication... but the ATM doesn't have any accounts, so its key and certificate can't be used alone to compromise any accounts. Then, Imagine USB ATM cards that could be plugged in, with an attendant please enter your PIN message on the screen of the ATM that would unlock your private key, so that the ATM could then initiate a renegotiation as you... and the server initiates renegotiations every 6 seconds to ensure that you're still there. Then, when you remove your USB stick, the machine reauthenticates as itself. This is not necessarily the best example of an architecture for this, but the principle can work anywhere you need a trusted host to perform a transaction.) As I think I mentioned, nobody ever actually mapped out the precise semantics of how the green bar is supposed to work. That is EV's biggest Achilles's Heel... nobody knows what it means, the same way nobody knew what the lock meant. I think, most people take security in a very pragmatic way. It should not cost additional efforts, but the investable efforts effectively limit the reachable security. OT: I personally would wish to be able to put a browser tab or better even a browser instance into some `secured' mode (for online banking HTTPS but not for myspace HTTPS). In this mode, flash would not work, no plug-ins installed and I would be Note: My bank's multi-factor authentication mechanism uses Flash, so it would be necessary for each site to provide a manifest of what it makes use of and what the maximum privileges each should have on the user's system. However, this is a very good idea. I don't know of any rendering engine or browser that would or could operate in this manner (other than possibly Chrome), but at that point we're still dealing with operating systems that can be compromised by viruses. warned when the DN of a certificate of a web page changes (now, I'm warned only if CN does not match DNS name, but I would like to be informed: www.xyz.com now is DN=XYZ Ltd. UK but last time it was DN=XYZ Inc. US or so). Probably there are many This already exists and is called Petnames, you might wish to look for it on addons.mozilla.org. more nice security features that could be turned on. This would not prevent the twitter attack but maybe could make online banking attacks more expensive. In my case, my bank's multifactor authentication includes sending a numeric code to my phone that I then enter into their Flash applet. Online banking attacks are regrettably cheap and relatively easy at this point... MITB is the watchword nowadays. With firefox, this is possible using different profiles with MOZ_NO_REMOTE but this breaks other things (today, systems seem to rely on a single running browser instance). Yeah. or something like `ssh -X safeu...@localhost firefox' :) Ohh, and this would catch passwords `system modal' just like ssh-add can do. It is too bad when half of the password reaches
Re: utf8string vs printablestring mismatch in certificate checking
What are the new rules for canonicalization of names from UTF8 to printableString? -Kyle H On Tue, Jan 19, 2010 at 1:55 PM, Dr. Stephen Henson st...@openssl.org wrote: Here you'll see that now the issuer hash matches because 1.0.0 uses a different algorithm for computing hashes which relies on a form of canonical encoding. So the best I can suggest is using 1.0.0 which is currently in beta. For compatibility reasons we can't backport the modified algorithm to 0.9.8. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: utf8string vs printablestring mismatch in certificate checking
On Tue, Jan 19, 2010, Kyle Hamilton wrote: What are the new rules for canonicalization of names from UTF8 to printableString? It's not the full RFC5280 algorithm. It just translates characters rather naively to lower case and performs the necessary space folding. Enough to pass the PKITS RFC3280 tests. It also strips off the outer SEQUENCE header so it can be rapidly used to check name constraints. The encoding of that lot is shoved through SHA1. 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
Compare two certificate chains
Hi, Are there any options in OpenSSL to compare two certificate chains based on some parameters. Could the comparison parameters be fingerprints, validity, algorithm and other features like CRL url's ? Thanks, mohan __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Query about Meinberg NTPV4 4.2.4p7 client compatibility with other thirdparty NTPV4 servers
Thanks Viktor. I will check the usage of strcpy () and strlen (). I may have to contact the NTP developer's group for further clarifications. With best regards, Mathews Emmanuel Siemens Information Systems Ltd CTDC I IADT IN Survey No. 39, 41, 42 Block B, Salarpuria Infozone Electronic City Hosur Road, Bangalore - 560 100 Tel. : + 91 80 6711 1143 Fax. : + 91 80 6711 1600 mailto. : mathews.emmann...@siemens.com www.siemens.co.in -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Victor Duchovni Sent: Tuesday, January 19, 2010 8:37 PM To: openssl-users@openssl.org Subject: Re: Query about Meinberg NTPV4 4.2.4p7 client compatibility with other thirdparty NTPV4 servers On Tue, Jan 19, 2010 at 07:43:34PM +0530, Emmanuel, Mathews IN BLR SISL wrote: Inference: 'Meinberg NTPV4 4.2.4p7' client sends the ASSOC request and receive the ASSOC response from our server. But the Meinberg client again sends the ASSOC request to our server instead of sending the CERT request. This is the OpenSSL users list. It seems to me that question belongs on an NTP developer list. If you have a question about how to construct message digests, please ask that question, directly. A common pitfall, which I am guessing you did not fall into, but just in case: Make sure you don't use strlen() or strcpy(), ... with raw binary message digests, as these will contain null bytes, with a probability of 1/256 per byte. The odds of an MD5 digest containing no null bytes are: (255/256)^16 ~ 93.9% For SHA1 these drop to: (255/256)^20 ~ 92.5% perhaps your MD5 test was lucky, and SHA1 test was unlucky? If you are actually computing and copying the hash value correctly, the rest is material for an NTP protocol discussion list. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org Important notice: This e-mail and any attachment there to contains corporate proprietary information. If you have received it by mistake, please notify us immediately by reply e-mail and delete this e-mail and its attachments from your system. Thank You. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
