Re: OCB Authenticated Encryption
On 27 March 2013 12:04, Matt Caswell fr...@baggins.org wrote: On 27 March 2013 11:52, Michael Sierchio ku...@tenebras.com wrote: Does Phil still teach at UC Davis? You could always ask him directly for clarification or a waiver. Hi contact details are on the web page describing the various license options (and yes its a UC Davis email address). It would be good if someone from OSF at least had a discussion with him. It would be a shame not to implement this excellent mode simply for not asking the right questions! The OSF is not actually the one that would benefit from such a licence, so the whole idea that it (or we) should pay for one seems weird to me. Matt __ 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
DTLS fails handshake due to early CHANGE_CIPHER_SPEC
tl;dr: I've been looking into an issue in my product (uses DTLS) for the last couple of days. Tracked it down to a CHANGE_CIPHER_SPEC being processed too early causing the handshake to never complete. Details: - OpenSSL version 1.0.1c - Brackets indicate a single datagram packet. (1) Client: send [SSL3_MT_CLIENT_HELLO] (2) Server: send [SSL3_MT_SERVER_HELLO, SSL3_MT_CERTIFICATE, SSL3_MT_CERTIFICATE_REQUEST, SSL3_MT_SERVER_DONE] (3) Client: send [SSL3_MT_CERTIFICATE, SSL3_MT_CLIENT_KEY_EXCHANGE, SSL3_MT_CERTIFICATE_VERIFY, *CHANGE_CIPHER*, SSL3_MT_FINISHED] Client packet (3) is lost. Oh noes! Other stuff happens, but Client eventually resends each message in its own datagram this time: (4) Client: send [SSL3_MT_CERTIFICATE] (5) Client: send [SSL3_MT_CLIENT_KEY_EXCHANGE] (6) Client: send [SSL3_MT_CERTIFICATE_VERIFY] (7) Client: send [*CHANGE_CIPHER*] (8) Client: send [SSL3_MT_FINISHED] Now, one of the following thing happens: a) packet (6) is lost or, in my case, packet (7) arrives before (6). Unfortunately, when Server processes packet (7) it changes the cypher spec before the handshake is over. When (6) finally arrives, it's dropped by dtls1_read_bytes. Subsequent re-sends from Client are also ignored. Without having read any spec, and with my limited knowledge of the OpenSSL codebase, my naive interpretation is that the problem is caused by dtls1_accept setting change_cipher_spec_ok on SSL3_ST_SR_CERT_VRFY_* states. Commenting out that line definitely seems to fix the problem for me. Is this really the bug, or does that line plays a role in a different scenario? Cheers, -dan
[openssl.org #3025] Patch for 2012-A-0070 (UNCLASSIFIED)
Classification: UNCLASSIFIED Caveats: NONE Hello, I'm running Apache 2.2.22 with OpenSSL 0.98t on Windows 2008R2. I installed the software bundle from the Apache Software Foundation. I need to correct the vulnerability 2012-A-0070, Multiple Remote Memory Corruption Vulnerabilities in OpenSSL or Update to OpenSSL 1.0.1a or later OR 1.0.0i or later OR 0.9.8w or later. I can't seem to find an install for OpenSSl or directions on how I can fix the vulnerability or upgrade OpenSSL. I've tried downloading tar files but they are not supported for Windows. I've managed to extract them using 7Zip but I don't see any install files for Windows. Please help! Thanks, Dennis Ramkelawan Systems Administrator 3-D Modeling Infrastructure Team Picatinny Arsenal (UTRS Contractor) 973-724-9521 Classification: UNCLASSIFIED Caveats: NONE __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #3026] Possible BUG in OpenSSL 1.0.1c regarding string types
Hello, I´m using OpenSSL 1.0.1c as a CA to sign a corporate certificate. OpenSSL is configured as follows: # This sets a mask for permitted string types. There are several options. # default: PrintableString, T61String, BMPString. # pkix : PrintableString, BMPString (PKIX recommendation before 2004) # utf8only: only UTF8Strings (PKIX recommendation after 2004). # nombstr : PrintableString, T61String (no BMPStrings or UTF8Strings). # MASK: a literal mask value. # WARNING: ancient versions of Netscape crash on BMPStrings or UTF8Strings. string_mask = utf8only All the strings that my certificate contains are UTF8String, but when trying to sign it with OpenSSL CA, it returns the following mismatch error: The countryName field needed to be the same in the CA certificate DE and the request DE When parsing the OpenSSL CA certificate, I found out the countryName field is coded as PrintableString, while in my certificate is coded as UTF8String, hence the error. The rest of the string fields are coded as UTF8String in both the CA certificate and the request. My question here is, if OpenSSL string_mask is configured as utf8only, why is the countryName field coded as PrintableString? Shouldn´t all fields be coded as UTF8String? Perhaps I misunderstood the meaning and use of the string_mask, so I would greatly appreciate if you could explain to me whether this is a bug or just correct behaviour. Thanks a lot in advance for your help. Best regards, Joseba Gil __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-dev] [openssl.org #3026] Possible BUG in OpenSSL 1.0.1c regarding string types
The countryName field is a PrintableString, that's mandatory (see X.520). It also MUST be 2 characters long, but that's not enforced by OpenSSL. -- Erwann ABALEA Le 28/03/2013 14:33, Joseba Gil Irisarri via RT a écrit : Hello, I´m using OpenSSL 1.0.1c as a CA to sign a corporate certificate. OpenSSL is configured as follows: # This sets a mask for permitted string types. There are several options. # default: PrintableString, T61String, BMPString. # pkix : PrintableString, BMPString (PKIX recommendation before 2004) # utf8only: only UTF8Strings (PKIX recommendation after 2004). # nombstr : PrintableString, T61String (no BMPStrings or UTF8Strings). # MASK: a literal mask value. # WARNING: ancient versions of Netscape crash on BMPStrings or UTF8Strings. string_mask = utf8only All the strings that my certificate contains are UTF8String, but when trying to sign it with OpenSSL CA, it returns the following mismatch error: The countryName field needed to be the same in the CA certificate DE and the request DE When parsing the OpenSSL CA certificate, I found out the countryName field is coded as PrintableString, while in my certificate is coded as UTF8String, hence the error. The rest of the string fields are coded as UTF8String in both the CA certificate and the request. My question here is, if OpenSSL string_mask is configured as utf8only, why is the countryName field coded as PrintableString? Shouldn´t all fields be coded as UTF8String? Perhaps I misunderstood the meaning and use of the string_mask, so I would greatly appreciate if you could explain to me whether this is a bug or just correct behaviour. Thanks a lot in advance for your help. Best regards, Joseba Gil __ 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: [openssl-dev] [openssl.org #3026] Possible BUG in OpenSSL 1.0.1c regarding string types
The countryName field is a PrintableString, that's mandatory (see X.520). It also MUST be 2 characters long, but that's not enforced by OpenSSL. -- Erwann ABALEA Le 28/03/2013 14:33, Joseba Gil Irisarri via RT a écrit : Hello, I´m using OpenSSL 1.0.1c as a CA to sign a corporate certificate. OpenSSL is configured as follows: # This sets a mask for permitted string types. There are several options. # default: PrintableString, T61String, BMPString. # pkix : PrintableString, BMPString (PKIX recommendation before 2004) # utf8only: only UTF8Strings (PKIX recommendation after 2004). # nombstr : PrintableString, T61String (no BMPStrings or UTF8Strings). # MASK: a literal mask value. # WARNING: ancient versions of Netscape crash on BMPStrings or UTF8Strings. string_mask = utf8only All the strings that my certificate contains are UTF8String, but when trying to sign it with OpenSSL CA, it returns the following mismatch error: The countryName field needed to be the same in the CA certificate DE and the request DE When parsing the OpenSSL CA certificate, I found out the countryName field is coded as PrintableString, while in my certificate is coded as UTF8String, hence the error. The rest of the string fields are coded as UTF8String in both the CA certificate and the request. My question here is, if OpenSSL string_mask is configured as utf8only, why is the countryName field coded as PrintableString? Shouldn´t all fields be coded as UTF8String? Perhaps I misunderstood the meaning and use of the string_mask, so I would greatly appreciate if you could explain to me whether this is a bug or just correct behaviour. Thanks a lot in advance for your help. Best regards, Joseba Gil __ 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
[openssl.org #3026] Possible BUG in OpenSSL 1.0.1c regarding string types
On Thu Mar 28 14:33:41 2013, joseb...@hotmail.com wrote: Hello, I´m using OpenSSL 1.0.1c as a CA to sign a corporate certificate. OpenSSL is configured as follows: # This sets a mask for permitted string types. There are several options. # default: PrintableString, T61String, BMPString. # pkix : PrintableString, BMPString (PKIX recommendation before 2004) # utf8only: only UTF8Strings (PKIX recommendation after 2004). # nombstr : PrintableString, T61String (no BMPStrings or UTF8Strings). # MASK: a literal mask value. # WARNING: ancient versions of Netscape crash on BMPStrings or UTF8Strings. string_mask = utf8only All the strings that my certificate contains are UTF8String, but when trying to sign it with OpenSSL CA, it returns the following mismatch error: The countryName field needed to be the same in the CA certificate DE and the request DE When parsing the OpenSSL CA certificate, I found out the countryName field is coded as PrintableString, while in my certificate is coded as UTF8String, hence the error. The rest of the string fields are coded as UTF8String in both the CA certificate and the request. My question here is, if OpenSSL string_mask is configured as utf8only, why is the countryName field coded as PrintableString? Shouldn´t all fields be coded as UTF8String? Perhaps I misunderstood the meaning and use of the string_mask, so I would greatly appreciate if you could explain to me whether this is a bug or just correct behaviour. The string_mask option only applies to DN fields of type DirectoryString which are a CHOICE of different string types. The countryName field can only be a PrintableString (see RFC5280 et al) . Coding it as any other string type violates the standards. 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 Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: OCB Authenticated Encryption
On 27 March 2013 21:03, Ben Laurie b...@links.org wrote: The OSF is not actually the one that would benefit from such a licence, so the whole idea that it (or we) should pay for one seems weird to me. Well, I wasn't actually suggesting that the OSF should pay for it itself, merely that the OSF could be the conduit for organising the licensing (in much the same way as it has been the conduit for organising the FIPS certification). The licensing only impacts US users of OpenSSL (as I understand it the patents under discussion here are only applicable within the US), and therefore the benefits would be largely felt by its customers -although in reality we all benefit by removing a blocker from integrating a mode into the code base with some significant advantages (OCB is supposedly significantly faster than GCM). If it comes to paying for it then I would hope that it may be possible to achieve sufficient corporate sponsorship to cover the costs (as I said in my original email). However, at this stage, all that is required is for someone to open a discussion with Phil Rogaway to see what can be achieved (maybe he will grant OpenSSL a waiver without any money changing hands at all). My suggestion is that that discussion could be initiated by the OSF (it seems a natural fit to me)...but really it could be anyone from the core dev team who can claim to speak for the project. Matt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: CPU Software Engine
Hi, Costas Stasimos wrote: Hi Jan By applying the cryptodev patch in openssl, all the applications that use openssl (postfix, tomcat etc) are automatically executed at hardware. As far as it concerns the openssl speed, we can avoid the hardware acceleration by using the evp parameter. My wonder is how we can avoid the hardware acceleration from application side? Is there an engine name that we can use to run the application at software? the fact that 'openssl engine -t' shows an engine as available does not mean that it is automagically *used*; on my openssl 1.0.1e build I see 'rsax' and 'gost' as available engines but I am quite certain that they are not used unless I specify them on the command line OR if I load them in my code using something like ENGINE_load_builtin_engines(); HTH, JJK 2013/3/22 Jan Just Keijser janj...@nikhef.nl mailto:janj...@nikhef.nl Hi Costas, Costas Stasimos wrote: Hello! I'm currently using the cryptodev framework-engine with openssl-1.0.1e. By run the command # openssl engine -t (cryptodev) cryptodev engine [ available ] (dynamic) Dynamic engine loading support [ unavailable ] we can see that the cryptodev is the active-chosen engine. So it seems that all the cryptographic load is directed automatically to /dev/crypto via the cryptodev engine. My question is, how i can use the CPU instead of cryptodev, or with other words how i can disable the cryptodev from application level? Is there an engine id-name in order to change the activated cryptodev engine and send the execution to the Software-CPU? AFAIK the cryptodev engine won't be used unless you actually specify it on the command line, e.g. openssl speed -engine cryptodev -evp etc.
RE: [openssl.org #3025] Patch for 2012-A-0070 (UNCLASSIFIED)
Try http://www.apachehaus.com You will find what you need -Original Message- From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On Behalf Of Ramkelawan, Dennis P CTR via RT Sent: Thursday, March 28, 2013 8:31 AM Cc: openssl-dev@openssl.org Subject: [openssl.org #3025] Patch for 2012-A-0070 (UNCLASSIFIED) Classification: UNCLASSIFIED Caveats: NONE Hello, I'm running Apache 2.2.22 with OpenSSL 0.98t on Windows 2008R2. I installed the software bundle from the Apache Software Foundation. I need to correct the vulnerability 2012-A-0070, Multiple Remote Memory Corruption Vulnerabilities in OpenSSL or Update to OpenSSL 1.0.1a or later OR 1.0.0i or later OR 0.9.8w or later. I can't seem to find an install for OpenSSl or directions on how I can fix the vulnerability or upgrade OpenSSL. I've tried downloading tar files but they are not supported for Windows. I've managed to extract them using 7Zip but I don't see any install files for Windows. Please help! Thanks, Dennis Ramkelawan Systems Administrator 3-D Modeling Infrastructure Team Picatinny Arsenal (UTRS Contractor) 973-724-9521 Classification: UNCLASSIFIED Caveats: NONE __ 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
Supporting IPv6 literals in s_client?
Hey there, Apparently supporting ipv6 literals like [openssl s_client -connect '[2001:4f8:0:2::d]:443' in s_client is oft-asked for but never-implemented, to the point where there are blog articles like this out there: https://lwn.net/Articles/486369/, and most OSes that want to support this, are applying the patches themselves at all, if at all. It would be nice if there were a unified answer in the base distro. This is an already-solved problem. There are minor patches, which are already submitted (years ago) and which don't affect any of the production libraries, since s_client is really only supposed to be used for testing, so by making this change, it's not like you're going to break firefox, apache, and openSSH. Can anyone who actually has a commit-bit state why these haven't been added yet, privately to me if not on-list?. I asked (twice) on openssl-users and got zero response, so I'm trying here. -Dan -- It's like GTA, except you pay for it, and you're allowed to use the car. -Josh, on Zipcar on-demand car-rental, 3/20/05 Dan Mahoney Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org --- __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
