[openssl-users] FIPS: Common method executed in case of error
Hello, Is there a method that is always in the path of execution when a crypto error occurs ? The reason for asking is that I would like to very slightly modify the OpenSSL FIPS version so that it will write a file in tmpfs when an error occurs. That place will be observed by another app using inotify. Granted, modifying OpenSSL FIPS will void its FIPS certification. But then, the whole unit will be validated. Having a single place to modify would be quite an extraordinary thing. I have asked recently about a related topic and got some replies regarding the modification of applications, although modifying the library would provide a single package to modify. Steve has replied that indeed the validation will be lost - I wonder if that would have any impact on the total validation costs for a whole unit, OS and apps ? Would a non-modified FIPS OpenSSL library reduce the validation costs ? Any comments and suggestions welcomed, regards. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] How to disable all EXPORT Ciphers?
On Tue, Mar 10, 2015 at 08:44:57AM +, Christian Georg wrote: I understand that the downgrading of the ciphersuites is a bug in the library that should be patched. Doing this can however be dificult when talking about mobile apps that use OS Libraries. From my understanding the bug only works within the limit of chipersuites permitted by both the client and the server. That understanding is I believe wrong. Only the server needs to support EXPORT ciphers. The client just needs a vulnerable library. Therefore my asumption is if the server side does only offer strong ciphers I do not have to worry too much about the ability to exploit the FREAK vulnerability e.g. in android clients. Yes, if the server disables EXPORT ciphers the clients are safe with *that* server, but will remain vulnerable with other servers. The clients do need to be patched. -- Viktor. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] FIPS: Common method executed in case of error
From: Steve Marquess marqu...@openssl.com Date: 03/10/15 08:56 Hello, Thanks for your reply. You're talking about a Level 2 validation (or higher)? You most definitely do *not* want to include the OS or applications in the cryptographic module boundary for Level 1. It's a level 2. The behaviour of the unit as a whole is validated. As an example amongst many, there will be no Linux console prompt available in FIPS mode. I think you're going to be shocked at the cost (in time and money) to validate a hacked OpenSSL FIPS module, compared to using it as-is or a change letter update. That brings a question. I'm currently using 1.0.1k with the 2.0 FIPS module for development purposes. This may seem a bit blunt, but, is it possible at all to use 1.0.1k to benefit from the FIPS validation ? Based on recent comments I would think not. Going back to a pre-heartbleed version ? Is there any way to benefit from the gained OpenSSL FIPS validation at all ? That's because the CMVP has introduced a number of new requirements since the current FIPS module was validated (in 2012), and any new validation will now need to satisfy those. Again, is there any benefit to be gained from using a once validated OpenSSL FIPS ? What would be the bugs fixed/ security updates trade-off ? That means not only non-trivial code hacks unrelated to yours, but also a new paper shuffle for the arm waving (DTR) components of the validation process. The cost of the latter dwarfs the former; which is why we have not attempted a new validation ourselves. Hmmm... If this goes through, would it be possible for OpenSSL to benefit from any validation our unit can get ? But, that cost could be dwarfed in turn by that of a Level 2 or 3 validation of a turnkey system including OS and apps. Thanks again for your comments, much appreciated. Regards. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] FIPS: Common method executed in case of error
On 03/10/2015 08:20 AM, jonetsu wrote: ... Steve has replied that indeed the validation will be lost - I wonder if that would have any impact on the total validation costs for a whole unit, OS and apps ? You're talking about a Level 2 validation (or higher)? You most definitely do *not* want to include the OS or applications in the cryptographic module boundary for Level 1. Would a non-modified FIPS OpenSSL library reduce the validation costs ? I think you're going to be shocked at the cost (in time and money) to validate a hacked OpenSSL FIPS module, compared to using it as-is or a change letter update. That's because the CMVP has introduced a number of new requirements since the current FIPS module was validated (in 2012), and any new validation will now need to satisfy those. That means not only non-trivial code hacks unrelated to yours, but also a new paper shuffle for the arm waving (DTR) components of the validation process. The cost of the latter dwarfs the former; which is why we have not attempted a new validation ourselves. But, that cost could be dwarfed in turn by that of a Level 2 or 3 validation of a turnkey system including OS and apps. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] FIPS: Common method executed in case of error
On Tue, Mar 10, 2015, jonetsu wrote: Hello, Is there a method that is always in the path of execution when a crypto error occurs ? The reason for asking is that I would like to very slightly modify the OpenSSL FIPS version so that it will write a file in tmpfs when an error occurs. That place will be observed by another app using inotify. Granted, modifying OpenSSL FIPS will void its FIPS certification. But then, the whole unit will be validated. Having a single place to modify would be quite an extraordinary thing. I have asked recently about a related topic and got some replies regarding the modification of applications, although modifying the library would provide a single package to modify. Steve has replied that indeed the validation will be lost - I wonder if that would have any impact on the total validation costs for a whole unit, OS and apps ? Would a non-modified FIPS OpenSSL library reduce the validation costs ? Any comments and suggestions welcomed, regards. Although you cannot modify the FIPS module itself without voiding the validation you *can* change the FIPS capable OpenSSL. You might (for example) change FIPS_mode_set() to always add a callback which logs any errors. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] FIPS: Common method executed in case of error
Is there a method that is always in the path of execution when a crypto error occurs ? It looks like fips_set_selftest_fail() would be a likely candidate where to create an empty file on a tmpfs in order to let the OS know about the error. Comments and suggestions welcomed. Based on your experience with FIPS validation process, and many customers/sponsors, do you think that having a ever so slightly modified OpenSSL FIPS code would increase validation costs for a whole unit (OS and apps) ? Recently Steve, I think, has mentioned that the cost for an initial OpenSSL FIPS validation was well into the 6 numbers. Would this type of figure be added to a project if OpenSSL FIPS is modified ? I think the labs could go with a diff and see how simple the modification is. Regards. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] How to disable all EXPORT Ciphers?
Viktor's description agrees with Matthew Green's explanation.[1] The FREAK attack can work against non-patched OpenSSL clients even if they disable export-grade ciphers; in fact, that's precisely the problem. The attack works like this: 1. Client sends ClientHello with a suite list that includes strong RSA suites. 2. MITM modifies ClientHello to request export-grade RSA. 3. If the server supports export-grade RSA, it replies with a 512-bit RSA key. 4. The client incorrectly accepts the short RSA key, even though it didn't ask for one. That's the bug. 5. Attacker factors the 512-bit RSA key. This relies on the second problem described by the FREAK authors: many servers (eg Apache) just generate one 512-bit RSA key pair at startup, and don't create a new one for each export-grade request, because it's expensive. So if you factor it once, you're good to break a whole bunch of sessions. If you always control both ends of the conversation, and can disable the export suites on both, then you shouldn't be vulnerable. If you have to talk to third-party servers, though, you don't know which ones might be vulnerable. FREAK testing has revealed that an awful lot still support the export suites. [1] http://blog.cryptographyengineering.com/2015/03/attack-of-week-freak-or-factoring-nsa.html From: openssl-users [openssl-users-boun...@openssl.org] on behalf of Viktor Dukhovni [openssl-us...@dukhovni.org] Sent: Tuesday, March 10, 2015 06:53 To: openssl-users@openssl.org Subject: Re: [openssl-users] How to disable all EXPORT Ciphers? On Tue, Mar 10, 2015 at 08:44:57AM +, Christian Georg wrote: I understand that the downgrading of the ciphersuites is a bug in the library that should be patched. Doing this can however be dificult when talking about mobile apps that use OS Libraries. From my understanding the bug only works within the limit of chipersuites permitted by both the client and the server. That understanding is I believe wrong. Only the server needs to support EXPORT ciphers. The client just needs a vulnerable library. Therefore my asumption is if the server side does only offer strong ciphers I do not have to worry too much about the ability to exploit the FREAK vulnerability e.g. in android clients. Yes, if the server disables EXPORT ciphers the clients are safe with *that* server, but will remain vulnerable with other servers. The clients do need to be patched. -- Viktor. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users This message has been scanned for malware by Websense. www.websense.com ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] FIPS_module_version_text()
Hmm. I am pretty sure I was linking against the FIPS capable OpenSSL but I will double check tomorrow to make sure I did it right. Thanks. On Mar 10, 2015, at 7:28 PM, Dr. Stephen Henson st...@openssl.org wrote: On Tue, Mar 10, 2015, Jason Schultz wrote: Is this function available to call in OpenSSL 1.0.1? I'm trying to call it from my application running a FIPS capable version of OpenSSL (everything else works, turning FIPS on, etc), but I include fips.h but I get a compile error saying the function was not declared. That's odd. I just compiled OpenSSL 1.0.1 and FIPS_module_version_text was present in libcrypto.so. Are you linking against the FIPS capable OpenSSL or the system supplied one? Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] How to make a rehandshake(renegotiation)?
Nobody knows? Does OpenSSL support renegotiation? I will be very grateful for answers because there is no any info about this in the net. 09.03.2015, 00:36, Serj Rakitov ra...@yandex.com: Hello I want to test SSL_ERROR_WANT_READ/SSL_ERROR_WANT_WRITE. I have client and server. Server is sending data to the client. Client is reading data. After some bytes sent server initiates a rehandshake to cause SSL_ERROR_WANT_WRITE on client. But there is no rehandshake. On server SSL_do_handshake returns 0 and SSL_get_error returns SSL_ERROR_WANT_READ. And on client SSL_read returns0 and SSL_get_error also returns SSL_ERROR_WANT_READ. The code to rehandshake is: SSL_set_session_id_context(...); SSL_renegotiate(...) SSL_do_handshake(...); ssl-state=SSL_ST_ACCEPT; //process SSL_do_handshake (WANT_READ/WANT_WRITE) How to make a rehandshake from server side? Best Regards, Serj Rakitov ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Getting info on the ciphers supported by a client
On 09/03/2015 14:13, Waldin wrote: Am 08.03.2015 um 09:14 schrieb Waldin: Now, I also want to check ciphers enabled in (mobile) mail clients. I've tried to make OpenSSL listen on port 110 (for POP with TLS) and redirected the client to the OpenSSL server. But when trying to pull mail I can't see any handshake information: FTR, I've now managed to check my mobile mail client. The hint was the argument to the s_client command's -starttls option, which made me realize that for handshaking with starttls a minimum understanding of the protocol is needed. OpenSSL probably doesn't include a POP or IMAP server. But it works without starttls, when listening on port 993: openssl s_server -cert public.pem -key ca-key.pem -accept 993 Enter pass phrase for ca-key.pem: Loading 'screen' into random state - done Using default temp DH parameters ACCEPT -BEGIN SSL SESSION PARAMETERS- MFUCAQECAgMBBAIAOQQABDAM5TDoa/9vlS6pUsqtlPWpgpMc1L7bvwCS5UGiIhut 13A4uf0Zm8T2/q3ULkxnkPKhBgIEVP2ataIEAgIBLKQGBAQB -END SSL SESSION PARAMETERS- Shared ciphers:DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:AES256-SHA:EDH-RSA-DES-CBC3 -SHA:EDH-DSS-DES-CBC3-SHA:DES-CBC3-SHA:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:AES 128-SHA:IDEA-CBC-SHA:RC4-SHA CIPHER is DHE-RSA-AES256-SHA Secure Renegotiation IS NOT supported ~A1 LOGIN MYLOGIN MYPASSWORD ERROR shutting down SSL CONNECTION CLOSED ACCEPT Hurray! But wait, a plain text password? And no server certificate pinning? Oh, no! Yep, that is essentially what the e-mail protocols allowin most real world scenarios. Note however that the password is SSL/TLS encrypted, which is why some mail clients and servers are quite insistant on having that enabled. For example, the usual configuration of the e-mail servers recommended by the Debian distribution (exim SMTP and courier POP3/IMAP), the default configuration is for the server to not even ask for a password until SSL/TLS is active, the only thing a client can do in plaintext is to ask for STARTTLS, or deliver remote mail (which obviously doesn't require a password). But at least the client should refuse if the certificate does not match the DNS name or IP address it was trying to contact (not to be confused with whatever name the server returns in protocol messages such as the SMTP banner). Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] SSL_ERROR_WANT_READ, SSL_ERROR_WANT_WRITE
Nobody knows? 09.03.2015, 15:30, Serj Rakitov ra...@yandex.com: I have to open discussion again. I want to test situations when SSL_read WANT_WRITE and SSL_write WANT_READ. But I can't do this. SSL_read never wants write and SSL_write never wants read! I don't know how to catch these situations. I don't know how to rehandshake. I tried after connect and handshake to send data simultaneously both to server and to client and never got one of those situations, SSL_read only wanted to read and SSL_write only wanted to write, all data was received by both client and server. I don't even understand how SSL_write can want to read? In what cases? I can understand when SSL_read wants to write, for example when client got HelloRequest or server got a new ClientHello while reading data. But I can't test it, because I don't know how to start handshake again, how to perform a rehandshake(renegotiation). Can anybody help me? How to test these situations or how to perform a rehandshake? Best Regards, Serj Rakitov ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] FIPS: Common method executed in case of error
From: Dr. Stephen Henson st...@openssl.org Date: 03/10/15 10:21 Although you cannot modify the FIPS module itself without voiding the validation you *can* change the FIPS capable OpenSSL. You might (for example) change FIPS_mode_set() to always add a callback which logs any errors. I see. So this would actually enable benefiting (saving validation costs) from an intact recent OpenSSL 1.0.1k with all security fixes. FIPS_mode_set() is very straightforward to patch although it would only catch startup errors. Not the eventual errors from tests that are executed before each crypto use. And not the continuous RNG tests. Within the scope of OpenSSL itself, there is a fips_cipher_abort() that is called for each algo. That macro could perhaps be a good place. Although it would still not catch continuous RNG test failures. Regards. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Delay of email delivery for the list
On Tue, Mar 10, 2015 at 10:23:41PM +0300, Serj Rakitov wrote: Hello, I see some delay about 30-40 min for my emails. They arrive and I see them in the incoming messages in the list only after 30-40 min. And one email was delivered for 2 hours. Is it normal for the openssl-users@openssl.org? Some time ago I see an email with message: Welcome to the openssl-us...@mta.opensslfoundation.net mailing list! Maybe now when something have changed we must send emails to the openssl-us...@mta.opensslfoundation.net not to the openssl-users@openssl.org? The mta.opensslfoundation.net was only very temporary and should not be used. openssl-users@openssl.org works just fine and doesn't have any delay for me. You can always check the headers why or where it has any delay. Kurt ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] SSL_ERROR_WANT_READ, SSL_ERROR_WANT_WRITE
On 09/03/2015 13:21, Serj Rakitov wrote: I have to open discussion again. I want to test situations when SSL_read WANT_WRITE and SSL_write WANT_READ. But I can't do this. SSL_read never wants write and SSL_write never wants read! I don't know how to catch these situations. I don't know how to rehandshake. I tried after connect and handshake to send data simultaneously both to server and to client and never got one of those situations, SSL_read only wanted to read and SSL_write only wanted to write, all data was received by both client and server. I don't even understand how SSL_write can want to read? In what cases? I can understand when SSL_read wants to write, for example when client got HelloRequest or server got a new ClientHello while reading data. But I can't test it, because I don't know how to start handshake again, how to perform a rehandshake(renegotiation). Can anybody help me? How to test these situations or how to perform a rehandshake? Not having tested or read the relevant OpenSSL code, I presume that SSL_write could want a read if it has sent a handshake message, but not yet received the reply, thus it cannot (encrypt and) send user data until it has received and acted on the handshake reply message. Maybe the easier scenarios are at the start of a session, where the initial handshake has not yet completed, as happens in a HTTPS client (always writes a request before the first read) or a simple SMTPS server (always writes a banner line before the first read of client commands, except in some servers that do an early read to check if a broken/spammer client is trying to send before receiving the banner). -- Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] How to disable all EXPORT Ciphers?
From: openssl-users On Behalf Of Viktor Dukhovni Sent: Monday, March 09, 2015 12:47 On Mon, Mar 09, 2015 at 02:23:53PM +0530, Deepak wrote: kEDH:ALL:!ADH:!DES:!LOW:!EXPORT:+SSLv2:@STRENGTH with SSL_CTX_set_cipher_list() be good enough to disable EXPORT40, 56 and 1024? You only need worry about the original exports retronymed EXPORT40. EXPORT56 was a draft RFC that was not adopted, and the SSL_CIPHER blocks still in source are disabled by a macro hardcoded in tls1.h (q.v.). EXP1024-blah would be the names of the nonexistent EXPORT56 ciphers. Note that doing so does not address the FREAK CVE in SSL clients. Even with EXPORT ciphers disabled they are still vulnerable, unless patched! Yes. As for your proposed cipherlist it is too exotic. * ALL:!ADH is simply DEFAULT. DEFAULT already prefers PFS (including ECDHE) and is sorted by strength. For 1.0.0+ DEFAULT is ALL:!aNULL:!eNULL:!SSLv2; !aNULL disables both ADH and AECDH. (0.9.8 excludes all ECC, including AECDH, unless ECCdraft.) !eNULL actually has no effect because ALL already excludes it; if you want eNULL (you shouldn't) you need the absurd-looking COMPLEMENTOFALL. * DES is a subset of LOW In fact DES is the only algorithm in LOW. (In math a set is a subset of itself and also a superset of itself but laypeople often don't expect that.) * I would also disable SSLv2, which is a subset of MD5, so I generally disable that instead which also drops the SSLv3's RC4-MD5 leaving RC4- SHA for interop. Note for many applications RC4 is no longer supposed to be used, consider whether disabling RC4 is appropriate for you. And disabling SSLv2 *ciphers* has the good effect of disabling SSLv2 *protocol* even if old or poor code calls SSLv23 and doesn't explicitly OP_NO_SSLv2. Therefore, I'd suggest: DEFAULT:!EXPORT:!LOW:!MD5 Which keeps things simple by starting with DEFAULT and removing what you want to disable. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] FIPS_module_version_text()
I guess I didn't have the correct fips.h file in my include path when I couldn't get it to compile. But I don't think it will work for my purposes since if I install my application on another system, that entry point is not defined in libcrypto.so or libssl.so. Does anyone know if it's really going to be added to 1.1.0? From: jetso...@hotmail.com To: openssl-users@openssl.org Subject: FIPS_module_version_text() Date: Tue, 10 Mar 2015 16:01:53 + Is this function available to call in OpenSSL 1.0.1? I'm trying to call it from my application running a FIPS capable version of OpenSSL (everything else works, turning FIPS on, etc), but I include fips.h but I get a compile error saying the function was not declared. I did find something in the CVS repository that says it was added to 1.1.0: http://marc.info/?l=openssl-cvsm=130982270901165 I feel like I'm missing something obvious... ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] How to make a rehandshake(renegotiation)?
Does OpenSSL support renegotiation? Yes. You probably need more than that. :) Take a look at the apps/s_client and look for the 'R' constant to see how to do client-initiated reneg. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Delay of email delivery for the list
Hello, I see some delay about 30-40 min for my emails. They arrive and I see them in the incoming messages in the list only after 30-40 min. And one email was delivered for 2 hours. Is it normal for the openssl-users@openssl.org? Some time ago I see an email with message: Welcome to the openssl-us...@mta.opensslfoundation.net mailing list! Maybe now when something have changed we must send emails to the openssl-us...@mta.opensslfoundation.net not to the openssl-users@openssl.org? Regards. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Delay of email delivery for the list
I see some delay about 30-40 min for my emails. They arrive and I see them in the incoming messages in the list only after 30-40 min. And one email was delivered for 2 hours. Is it normal for the openssl-users@openssl.org? It happens sometimes. Some time ago I see an email with message: Welcome to the openssl- us...@mta.opensslfoundation.net mailing list! The OpenSSL domains got shuffled around a bit. Everything should be openssl.org now. -- Senior Architect, Akamai Technologies IM: rs...@jabber.me Twitter: RichSalz ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] SSL_ERROR_WANT_READ, SSL_ERROR_WANT_WRITE
Hi, Jakob. Thanks for reply. Now I have seen OpenSSL code and something clear for me. WANT_READ/WANT_WRITE it's just an implementation for WOULDBLOCK: not fatal error for non-blocking IO. So, for example for socket and Windows it's just WSAEWOULDBLOCK returns by WSAGetLastError. Peforms by BIO_sock_should_retry/BIO_sock_non_fatal_error in sock_read/sock_write. There was some incomprehension for me because I forgot that SSL_read/SSL_write can perform a handshake if it didn't happen before. This is the key, because if handshake took place when SSL_write never will want read(to my mind), because it's just perform writesocket(send) operation. But with Rehandshaking (renegotiation) still incomprehension... I don't know why there is a silence about this here and in the net! I have read Eric Rescorla's old(January 10, 2002) article and there he told about Rehandshaking on the Server and on the Client, so it's possible with OpenSSL, but maybe in newer versions of OpenSSL it is not possible? Jakob, can you tell me: is it possible to renegotiate a connection in OpenSSL? And if yes how to do it right? 10.03.2015, 19:06, Jakob Bohm jb-open...@wisemo.com: Not having tested or read the relevant OpenSSL code, I presume that SSL_write could want a read if it has sent a handshake message, but not yet received the reply, thus it cannot (encrypt and) send user data until it has received and acted on the handshake reply message. Maybe the easier scenarios are at the start of a session, where the initial handshake has not yet completed, as happens in a HTTPS client (always writes a request before the first read) or a simple SMTPS server (always writes a banner line before the first read of client commands, except in some servers that do an early read to check if a broken/spammer client is trying to send before receiving the banner). ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] How to disable all EXPORT Ciphers?
Hi Viktor, please help me to understand your sentence: Note that doing so does not address the FREAK CVE in SSL clients. Even with EXPORT ciphers disabled they are still vulnerable, unless patched! I understand that the downgrading of the ciphersuites is a bug in the library that should be patched. Doing this can however be dificult when talking about mobile apps that use OS Libraries. From my understanding the bug only works within the limit of chipersuites permitted by both the client and the server. Therefore my asumption is if the server side does only offer strong ciphers I do not have to worry too much about the ability to exploit the FREAK vulnerability e.g. in android clients. I am very aware that on older Androids there are other things to worry about like missing TLS 1.2 support,... but with regards to freak SSL a quick fix to secure the communication between a mobile app and the server side webservice should be disabeling weak ciphers on the server. Is this assumption wrong ? Thanks for your help Chris --- -Ursprüngliche Nachricht- Von: openssl-users [mailto:openssl-users-boun...@openssl.org] Im Auftrag von Viktor Dukhovni Gesendet: Montag, 9. März 2015 17:47 An: openssl-users@openssl.org Betreff: Re: [openssl-users] How to disable all EXPORT Ciphers? On Mon, Mar 09, 2015 at 02:23:53PM +0530, Deepak wrote: How to I disable all EXPORT Ciphers from OpenSSL? Will the use of string kEDH:ALL:!ADH:!DES:!LOW:!EXPORT:+SSLv2:@STRENGTH with SSL_CTX_set_cipher_list() be good enough to disable EXPORT40, 56 and 1024? Note that doing so does not address the FREAK CVE in SSL clients. Even with EXPORT ciphers disabled they are still vulnerable, unless patched! As for your proposed cipherlist it is too exotic. * ALL:!ADH is simply DEFAULT. DEFAULT already prefers PFS (including ECDHE) and is sorted by strength. * DES is a subset of LOW * I would also disable SSLv2, which is a subset of MD5, so I generally disable that instead which also drops the SSLv3's RC4-MD5 leaving RC4-SHA for interop. Note for many applications RC4 is no longer supposed to be used, consider whether disabling RC4 is appropriate for you. Therefore, I'd suggest: DEFAULT:!EXPORT:!LOW:!MD5 Which keeps things simple by starting with DEFAULT and removing what you want to disable. -- Viktor. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] FIPS: Common method executed in case of error
On Tue, Mar 10, 2015, jonetsu wrote: From: Dr. Stephen Henson st...@openssl.org Date: 03/10/15 10:21 Although you cannot modify the FIPS module itself without voiding the validation you *can* change the FIPS capable OpenSSL. You might (for example) change FIPS_mode_set() to always add a callback which logs any errors. I see. So this would actually enable benefiting (saving validation costs) from an intact recent OpenSSL 1.0.1k with all security fixes. Only the FIPS module is validated: the FIPS capable OpenSSL uses it. So you can modify (within reason) the FIPS capable OpenSSL without affecting the validation . So you can use OpenSSL 1.0.1l or 1.0.2 with the FIPS module. FIPS_mode_set() is very straightforward to patch although it would only catch startup errors. Not the eventual errors from tests that are executed before each crypto use. And not the continuous RNG tests. I mean you could add a callback to FIPS_mode_set using FIPS_post_set_callback: see the fips_test_suite.c application for an example. The supplied callback is called during each POST, continuous RNG and pairwise consistency checks. The op value is set to FIPS_POST_FAIL if any test fails. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] FIPS_module_version_text()
On Tue, Mar 10, 2015, Jason Schultz wrote: Is this function available to call in OpenSSL 1.0.1? I'm trying to call it from my application running a FIPS capable version of OpenSSL (everything else works, turning FIPS on, etc), but I include fips.h but I get a compile error saying the function was not declared. That's odd. I just compiled OpenSSL 1.0.1 and FIPS_module_version_text was present in libcrypto.so. Are you linking against the FIPS capable OpenSSL or the system supplied one? Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
