Re: [openssl.org #2879] AutoReply: Bug report - X509_check_akid() incorrectly handles dirName:
Please close this ticket. It is wrong. On 9/13/2012 3:15 AM, The default queue via RT wrote: > > Greetings, > > This message has been automatically generated in response to the > creation of a trouble ticket regarding: > "Bug report - X509_check_akid() incorrectly handles dirName:", > a summary of which appears below. > > There is no need to reply to this message right now. Your ticket has been > assigned an ID of [openssl.org #2879]. > > Please include the string: > > [openssl.org #2879] > > in the subject line of all future correspondence about this issue. To do so, > you may reply to this message. > > Thank you, > r...@openssl.org > > - > Using: > Windows 7 Professional SP1 > openssl-1.0.0g > > Build: > perl Configure debug-VC-WIN64A no-asm --prefix=c:\openssl > ms\do_win64a > nmake -f ms\nt.mak > > source file: > openssl-1.0.0g\crypto\x509v3\v3_purp.c > > function: > int X509_check_akid(X509 *issuer, AUTHORITY_KEYID *akid) > > line 762: > if(nm && X509_NAME_cmp(nm, X509_get_issuer_name(issuer))) > ^^ > I believe this should be: > if(nm && X509_NAME_cmp(nm, X509_get_subject_name(issuer))) > ^^^ > I have tested and verified this fix. > > Best regards, > --David Shambroom > __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-dev] [openssl.org #2879] Bug report - X509_check_akid() incorrectly handles dirName:
Thank you for the correction. Obviously the the authorityCertIssuer must correspond to the authorityCertSerialNumber. Please close this ticket. On 9/13/2012 4:40 AM, Erwann Abalea via RT wrote: Bonjour, The goal of this function is to determine if a given authorityKeyIdentifier extension matches an issuer certificate (issuer=authority). The AKI extension can contain 3 elements: - keyIdentifier - authorityCertIssuer - authorityCertSerialNumber (X.509 mandates that the last 2 MUST be present together, this constraint is not mentioned in RFC5280) The first element is to be compared with the issuer's subjectKeyIdentifier, is present. The 2nd and 3rd element are to be compared with the issuer's issuerName and issuer' serialNumber, respectively. They are here to uniquely identify a certificate, and a certificate is uniquely identified by its issuer's name and its own serial number. Therefore the fix is incorrect. If you've got a certificate chain that doesn't validate the AKI with the last 2 elements, it surely means your certificates are improperly constructed. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-dev] [openssl.org #2879] Bug report - X509_check_akid() incorrectly handles dirName:
Thank you for the correction. Obviously the the authorityCertIssuer must correspond to the authorityCertSerialNumber. Please close this ticket. On 9/13/2012 4:40 AM, Erwann Abalea via RT wrote: > Bonjour, > > The goal of this function is to determine if a given > authorityKeyIdentifier extension matches an issuer certificate > (issuer=authority). > > The AKI extension can contain 3 elements: >- keyIdentifier >- authorityCertIssuer >- authorityCertSerialNumber > > (X.509 mandates that the last 2 MUST be present together, this > constraint is not mentioned in RFC5280) > > The first element is to be compared with the issuer's > subjectKeyIdentifier, is present. > > The 2nd and 3rd element are to be compared with the issuer's issuerName > and issuer' serialNumber, respectively. > They are here to uniquely identify a certificate, and a certificate is > uniquely identified by its issuer's name and its own serial number. > > Therefore the fix is incorrect. If you've got a certificate chain that > doesn't validate the AKI with the last 2 elements, it surely means your > certificates are improperly constructed. > __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2879] Bug report - X509_check_akid() incorrectly handles dirName:
Using: Windows 7 Professional SP1 openssl-1.0.0g Build: perl Configure debug-VC-WIN64A no-asm --prefix=c:\openssl ms\do_win64a nmake -f ms\nt.mak source file: openssl-1.0.0g\crypto\x509v3\v3_purp.c function: int X509_check_akid(X509 *issuer, AUTHORITY_KEYID *akid) line 762: if(nm && X509_NAME_cmp(nm, X509_get_issuer_name(issuer))) ^^ I believe this should be: if(nm && X509_NAME_cmp(nm, X509_get_subject_name(issuer))) ^^^ I have tested and verified this fix. Best regards, --David Shambroom -- W. David Shambroom, Ph.D. Security Architect, InterSystems Corporation w...@intersystems.com; 617.551.2143; fax: 617.494.1631 __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-dev] Re: How to locate the X.509 specifications
RFC 5280 is just what it says it is: "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile" "tailored for the Internet" (Section 3.1) No one said that it's anything more. Don't use it if you don't like it, but it's worth knowing about. Erwann ABALEA wrote: Hodie VII Id. Aug. MMX, David Shambroom scripsit: See: http://www.ietf.org/rfc/rfc5280.txt RFC5280 is only a profile for X.509 certificates and CRLs, just were RFC3280 and RFC2459 before it. Hopefully, RFC5280 is of better quality than its predecessors, but doesn't replace the standard at all. It adds more constraints, some of them are unnecessary (for example an organizationName or a commonName limited to 64 characters). RFC acts on top of X.509, and only for public key certificates (i.e. not attribute certificates). Kyle Hamilton wrote: I was asked this morning where to find the X.509 specification, since http://itu.int/ is such a messy website. It's sad the 2008 version is only available for a fee. I always thought the free 2005 version (and corresponding X.5xx standards covering other important aspects) was a good thing to help development. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: How to locate the X.509 specifications
See: http://www.ietf.org/rfc/rfc5280.txt Kyle Hamilton wrote: I was asked this morning where to find the X.509 specification, since http://itu.int/ is such a messy website. I'll point you to the general location, because it's a better piece of information to have than the exact location. (There are other recommendations that X.509 refers to, and being able to find *all* of them is key to being able to understand the spec.) The sector that we are interested in is called "ITU-T, Standardization" (as opposed to ITU-R, Radiocommunications). http://www.itu.int/en/ITU-T/publications/Pages/recs.aspx To get to X.509 from there, click the 'X' (above Y and Z), for 'Data networks, open system communications and security". That'll take you to: http://www.itu.int/itu-t/recommendations/index.aspx?ser=X . This is a tree view; you want the node labelled 'X.500-X.599: Directory'. Then, select X.509 (it's the third in the tree). The 11/2008 version (Edition 6) is only available for a fee (85 Swiss Francs), and so the version that I work from is Edition 5 (which is available for no fee). And, according to XE.com, CHF 1,00 represents USD $0.9626 at midmarket rates today (2010/08/07). -Kyle H __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
TLSv1.2
What are the thoughts of the core development team about the prospects for adding full RFC 5246 (TLS 1.2) support to the libraries? (I looked in the archives and didn't find much, although that doesn't necessarily mean it's not in there.) Very roughly speaking, what do you think the resource requirements would be if a reasonably competent outside party were to undertake this? (I think that they would be substantial.) Would anybody be willing to guess what the cost might be if an outside party were to sponsor this work? I admit up front that I am asking not because of any specific technical requirement, but rather a perceived regulatory requirement. Feel free to contact me privately if you prefer. TIA, --David __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: TLS CA Certificate Loading in DER format
d2i_X509_fp() Chaitra Shankar wrote: Hi, I am to use TLS for securing an application's data transfer. For development purposes I have been using a dummy set of certificates in PEM format. The currently used "SSL_CTX_load_verify_locations" API requires that the certificate be in PEM format. However, in real time scenario, the application being developed MUST make use of certificates in DER format as per the requirements. So I wanted to know whether there is a way to load CA certificates in DER format using any SSL APIs. My search till now for such an API has been unfruitful. Thanks in Advance. -- Thanks & Regards Chaitra Shankar __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Determining if client requests ssl handshake
Actually, a TLS/SSLv3 ClientHello message begins with the byte sequence: offset value 0x000x16content type Handshake 0x010x03major version 0x020x00-0x03 minor version 0x030x length 0x050x01handshake type ClientHello RFC5246, Appendix A. Kyle Hamilton wrote: A client has a sign that a server wants to negotiate TLS if it receives a byte 0x00 (the code for 'HelloRequest'). A server has a sign that a client wants to negotiate TLS if it receives a byte 0x01 (ClientHello). There are multiple ways to use TLS. The one that webservers use is to create the TLS-encrypted tunnel across TCP, then exchange all application data over it. The one that IMAP, ESMTP, and various other state-keeping, text-based protocols with the ability to send binary across the same connection use is to create a specific text-based command -- typically STARTTLS -- that causes the server to send out a HelloRequest. The typical sequences that I've been looking at for my apps lately, by the way, are: Receive: (unicode byte order mark, describing precisely which encoding the client's using) STARTTLS (server sends HelloRequest) (client sends ClientHello) Receive: ClientHello (negotiate TLS) Receive: Unicode BOM (server assumes client is using Unicode) Receive: Telnet IAC (0xff) (server negotiates telnet parameters, including possibly Unicode) Receive: anything else (server assumes client is using ISO-Latin-1) However, this is primarily for a couple of text-based MUD softwares that I'm working with. Your mileage may vary. -Kyle H On Mon, Jul 6, 2009 at 11:51 AM, Konstantin Ivanov wrote: Hi all, I was wondering if it is possible to determine if client is requesting an ssl handshake on regular socket connection and if client does request it, continue with SSL handshake and enable secure communication? What is happening is that if I have a server, but I accept a connection using a regular socket (not OpenSSL accept) then I get the scrambled data from the client which I assume is an attempt to handshake with the server. Is it possible to determine if this is a handshake and if so, let this connection be secure? This is a custom application. Thank you, K __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Couldn't obtain random bytes in sshd - problem in RAND_poll?
Kyle, I didn't say that /dev/urandom was safe to use for cryptographic purposes. It isn't, and I didn't then and don't now advise its use. I said it never blocks. It doesn't. So what was incorrect? Kyle Hamilton wrote: David S: to my knowledge you're at least somewhat incorrect, and part of your advice is rather dangerous to rely upon (from a cryptographic theory perspective). /dev/urandom will never, under normal circumstances, block -- its output is generated algorithmically by the random/urandom device driver. (It's akin to reading from /dev/null or /dev/zero, in that the read is always handled by the kernel driver without having to wait for anything.) /dev/urandom will not block. /dev/random will block if there isn't enough entropy stirred into it. And yes, it is possible to "run out" the entropy pool. The amount of chaos that you stir in is the amount of chaos that you can pull out -- everything else is deterministic, and as the man page says there may be a theoretical way that the pseudorandom number generator can be attacked (though one is currently not known in the nonclassified literature) with the result that the keys generated will be predictable. If the pool is never seeded, the "randomness" won't ever be really random. If the pool is seeded once, the "randomness" will be random for as long as the amount of entropy in the seed holds out. After this, the numbers generated won't really be random. If the pool is continually re-seeded, the "randomness" will be random for as long as the amount of entropy in the seeds fed into it holds out. After this, the numbers generated won't really be random, until more entropy is stirred in -- and even then, that will be exhausted in the same way. The only way to guarantee that your numbers are truly cryptographically secure is to use /dev/random and deal with the fact that it will block until there's been enough entropy seeded into the randomness pool. Otherwise, many random number generators use a linear-feedback shift register with a periodicity of 2**56. That's approximately the same amount of keyspace as DES, and the output over multiple successions of readings of 2**56 bytes will repeat and not be suitably random. (If an attacker can figure out the state of your PRNG, the attacker can figure out your next-generated "secret" randomness. This is why the Debian debacle was so serious, and why only a few thousand possible keys were generated by the vulnerable implementations -- the randomness wasn't.) I'd certainly like to see references to the contrary, if they exist -- my references are the Handbook of Applied Cryptography and Applied Cryptography 2nd Ed. -Kyle H On Thu, Aug 7, 2008 at 2:13 AM, David Schwartz <[EMAIL PROTECTED]> wrote: David Shambroom wrote: You're right: You are completely wrong. /dev/urandom never blocks. See the man page. Is this is the excerpt from the man page you are referring to? A read from the /dev/urandom device will not block waiting for more entropy. As a result, if there is not sufficient entropy in the entropy pool, the returned values are theoretically vulnerable to a cryptographic attack on the algorithms used by the driver. Knowledge of how to do this is not available in the current non-classified liter- ature, but it is theoretically possible that such an attack may exist. If this is a concern in your application, use /dev/random instead. If so, this doesn't say that /dev/urandom never blocks. It just says that it will not block waiting for more entropy. In fact, this paragraph is horribly misleading, because it suggests that the worst thing /dev/urandom can do is return random values with a theoretical vulnerability. Alas, this is not true. The /dev/urandom interface will happily return entirely predictable values if the pool was never seeded. If the entropy pool was ever seeded, then it can produce cryptographically-strong entropy forever. You cannot run it out of entropy. However, if it was *never* seeded, it cannot produce even a single byte of crypotgraphically-strong entropy. Reading back over the post you are responding to, I realize that it reads to mean the complete opposite of what I was trying to say. I'm not sure how I managed to do that. I was very sloppy with my terms. What I was trying to address was the case where the pool was never seeded, not the case where the pool runs out of entropy. However, reading my words, it seems I somehow said the exact opposite of what I was thinking! Sadly, Linux suffers from a three bears problem. The /dev/random implementation will block even if cryptographically-strong randomness is available. The /dev/urandom implementation will happilly hand you numbers that are not cryptograhically-strong. There is no "just rig
Re: Couldn't obtain random bytes in sshd - problem in RAND_poll?
You're right: You are completely wrong. /dev/urandom never blocks. See the man page. David Schwartz wrote: Tried many many times, even two running at the same time or poll timeout set to zero, not one instance of blocking even with od -x /dev/urandom and od -x /dev/random running simultaneously (the second one blocks, of course). H.. what the #$%# is happening here.. more ideas? -- Stano My bet is that '/dev/urandom' only blocks if it doesn't have enough entropy. Early in the startup process, '/dev/urandom' doesn't have enough entropy, and your application times out on it. Later on, when the system has had lots of network activity, you log in and test '/dev/urandom'. At this point, the system is well-seeded from the network activity. So it works great for you. Try launching your test program automatically on boot up at the saem time you launch ssh or whatever application is failing. I bet '/dev/urandom' will fail then. If you have a network, one solution might be to do a few 'ping's or 'nslookup's to seed the entropy pool. You can also keep an entropy pool on disk, saving it on shutdown and loading it on startup. Or I could be completely wrong. DS __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1704] bug report, Windows VC-32 debug build
In util\pl\VC-32.pl, all instances of $dbg_cflags need to include the switch /Zi. Tested successfully with 0.9.8d and Visual C++ 8. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: UltraSPARC T1
I do. Contact information below. Andy Polyakov wrote: Does anybody have access to UltraSPARC T1-based system? A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] -- W. David Shambroom, Ph.D. Security Architect 617.551.2143 InterSystems Corporation[EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1454] RSA key exponents different from 3 and F4
Try openssl speed rsa Private key (large exponent) operations are 1-2 orders of magnitude slower than public key (small exponent), easily observed. Depending on key length and traffic volume this can be very important. --David Annie Yousar via RT wrote: Small exponents give the advantage of faster signature verification, but in fact you can't really observe that. A prime exponent e theoretically speeds up the prime factor search, remember that e must be coprime with (p-1) and (q-1), which is more likely if e is prime. But this is in the GHz Century also not very important. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Compiler otimization error on Solaris AMD64
The file openssl_0.9.8b/crypto/aes/aes_core.c is based on rijndael-alg-fst.c by Rijnmen, Bosselaers, and Barreto. I discovered in the context of another project that when this file is compiled on Solaris AMD64: $ uname -a SunOS opterondev 5.10 Generic i86pc i386 i86pc using Sun's compiler with the -fast option, the generated code produces incorrect output. The Configure target solaris64-x86_64-cc includes this option. Testing with: ./Configure solaris64-x86_64-cc make make test confirms that OpenSSL has inherited the problem: Testing cipher AES-128-ECB(encrypt) Key 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f Plaintext 00 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff Ciphertext 69 c4 e0 d8 6a 7b 04 30 d8 cd b7 80 70 b4 c5 5a Ciphertext mismatch Got c7 a8 a6 29 7a 35 71 44 21 e3 7a f9 e8 b5 bd af Expected 69 c4 e0 d8 6a 7b 04 30 d8 cd b7 80 70 b4 c5 5a I will be opening a support case with Sun. --David -- W. David Shambroom, Ph.D. Security Architect 617.551.2143 InterSystems Corporation[EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
