Re: [openssl-users] POODLE attack on TLS1.2
On 27.02.2017 13:03, Akshar Kanak wrote: Dear Team In https://en.wikipedia.org/wiki/POODLE , It is mentioned that POODLE attack is possible aganist *TLS *also . has this issue been alredy addressed in openssl . Thanks and regards Akshar As the corresponding section in the Wikipedia article says that is not a flaw in the TLS protocol but a flaw in it's implementations, more exactly in the implementation of CBC encryption mode. For being on the safe side take cipher suites not using CBC mode. Best regards, Richard -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Reload certificates?
On 18.05.2016 19:51, Salz, Rich wrote: Is there something I'm missing? Nope. From the description of SSL_CTX_load_verify_locations i would have expected that certificates loaded via the CApath mechanism are loaded anew for every verification process. If this is not the case an appropriate note in that description would be very nice. Ciao, Richard -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: Query: Disabling SSLv3
On 05.11.2014 17:00, Viktor Dukhovni wrote: On Wed, Nov 05, 2014 at 12:18:05PM +, Philip Bellino wrote: Jeffrey, May I ask why you included no-ssl2 as an option to config? Is only adding no-ssl3 not sufficient enough to fully disable SSLv3? No. If you leave SSLv2 enabled, and disable SSLv3, then in many cases you always get SSLv2! SSL/TLS clients advertise a range of protocols (min, max) not a list. If the min is SSLv2 and SSLv3 is disabled then the max is also SSLv2, unless explicitly disabled by the application, or use extensions forces SSLv3 or later. Well, the ClientHello message only allows to advertise the highest protocol version the client speaks, it is expected that the client speaks also all lower versions. Therefore, when a client isn't able or doesn't want to speak e.g. SSLv2, it has to wait for the ServerHello and to end the connection when the server selects an unwanted protocol version. Ciao, Richard __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Query on SSL client version to SSL server version
On 06.11.2014 10:02, Rajeswari K wrote: Hello Openssl users, I have a basic query that Lets say my SSL client is capable of versions SSL3.0 and SSL3.1. And my SSL server is capable of versions TLS1.0, TLS1.1 and TLS1.2 Now SSL client has sent a client hello with version SSL3.0. Since, SSL server doesn't have this version present, it returns version mismatch error. In this case, what should be the ideal scenario? Does SSL Client need to resend client hello with TLS1.0? Like on Server, does SSL client also will have fall back/up mechanisms in order to avoid version mismatch errors? Please clarify? SSL3.1 is the political incorrect name for TLS1.0 ;-), with this your example contains a client capable of versions SSLv3 and TLSv1 which should advertise TLSv1 right from the beginning which leads then to the server selecting TLSv1 as the highest/only common protocol version and no problem occurs. Best regards, Richard __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Query: Disabling SSLv3
On 06.11.2014 16:35, Viktor Dukhovni wrote: On Thu, Nov 06, 2014 at 03:31:10PM +0100, Richard K?nning wrote: Well, the ClientHello message only allows to advertise the highest protocol version the client speaks, it is expected that the client speaks also all lower versions. The client uses the lowest supported version at the *record layer*, and sends the highest at the *handshake layer*. The server chooses something in that *range*. Therefore, when a client isn't able or doesn't want to speak e.g. SSLv2, it has to wait for the ServerHello and to end the connection when the server selects an unwanted protocol version. I believe you're simply wrong about that. Having now read Appendix E of RFC 2246 i now know you are right :-). Ciao, Richard __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: SSLv23, POODLE and TLS_FALLBACK_SCSV
Am 25.10.2014 13:55, schrieb Jaya Nageswar: 2. In general, if we have SSLv23 protocol at both client and Server, How does the protcol negotiation happens? I have been reading that the client sends a client_hello message along with the other protocols supported and the cipher suites. The Server then sends its supported protocols/cipher suites and selects the highest protocol supported by client and Server in the order. Is my understanding correct? The client sends in the client_hello the highest SSL/TLS version it supports and a list of supported cipher suites. The server selects the highest protocol version compatible with the client abilities and selects one of the cipher suites the client offers and the server supports too. In older OpenSSL versions the server selects the first cipher suite in the list offered by the client, i.e. the client has strong influence which cipher suite is selected. In newer OpenSSL versions (don't ask me which ones, maybe its even only a proposal for future OpenSSL versions) afair there is a possibility that the server uses some other rules for selecting a cipher suite (i did a quick look for appropriate OpenSSL functions, but up to now i didn't find one which allows to influence the server as described before.) Best regards, Richard __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: SSL_MODE_SEND_FALLBACK_SCSV option
Am 24.10.2014 23:16, schrieb David Li: On Fri, Oct 24, 2014 at 1:28 PM, Richard Könning richard.koenn...@ts.fujitsu.com mailto:richard.koenn...@ts.fujitsu.com wrote: Am 24.10.2014 20:47, schrieb David Li: On Fri, Oct 24, 2014 at 11:18 AM, Richard Könning Richard.Koenning@ts.fujitsu.__com mailto:richard.koenn...@ts.fujitsu.com mailto:Richard.Koenning@ts.__fujitsu.com mailto:richard.koenn...@ts.fujitsu.com wrote: At 24.10.2014 19:03, David Li wrote: I am still a little unclear by what exactly TLS_FALLBACK_SCSV option would do. What if the server only supports SSLv3 + TLSv1 and client only connects with SSLv3? Without the patch, both would agree to SSLv3. So this is a problem. Well I thought it's the CBC cipher mode used by SSLv3 that has the problem. So we should avoid SSLv3 all together. Exactly. But when you have a client which speaks only SSLv3 as in your example below you have to decide: Don't use the client or enhance it so it speaks at least TLSv1 or use SSLv3 despite the problems with SSLv3. Maybe this is is my confusion. Will the SSLv3 alone cause the attack? Or will a downgrade process from TLS 1.0 or later to the SSLv3 expose the vulnerability? SSLv3 alone is vulnerable. When you decide that this vulnerability is so large that you don't want to use SSLv3 in any case than life is easy: deactivate the usage of SSLv3 in all clients and servers and you have not to think about fall back to SSLv3. But when your opinion is, that an SSLv3 connection is better than no connection than you may have to fall back to SSLv3 some times. The TLS_FALLBACK_SCSV helps you to ensure that the fall back is done only when SSLv3 is really the highest SSL/TLS protocol shared by client and server. So is it true that in this case TLS_FALLBACK_SCSV still can't prevent the attack since this is a totally legitimate honest fallback to SSLv3? In other words, the MITM attacker doesn't have to message the handshake at all. Your example, which i addressed, was a client using SSLv3 right from the start (for whatever reasons), in that case there is *no fallback*. If you set nevertheless the option TLS_FALLBACK_SCSV by the client than you will get no connection. The same result can be achieved by deinstalling the client. TLS_FALLBACK_SCSV can prevent the usage of SSLv3 when both partners are able to speak a better protocol. If SSLv3 is the best e.g. the client speaks than you have only the choice to communicate via the attackable SSLv3 (or even worse completely unencrypted) or to communicate not at all. Best regards, Richard __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: SSL_MODE_SEND_FALLBACK_SCSV option
At 24.10.2014 19:03, David Li wrote: I am still a little unclear by what exactly TLS_FALLBACK_SCSV option would do. What if the server only supports SSLv3 + TLSv1 and client only connects with SSLv3? Without the patch, both would agree to SSLv3. So this is a problem. Where is the problem? When the client only supports SSLv3 and therefore right away starts with SSLv3, then you get an SSLv3 connection as wanted. When you don't want any SSLv3 connections, remove the SSLv3 support in the server and enhance the client so it speaks also TLSv1 or better. What happens with the patch only on the server? And what happens with the both server and client patched? First question: nothing, because the client can't say to the server that the second handshake with SSLv3 is a fallback of a previous handshake announcing the availability of TLSv1 or better. Second question: When the client starts due to a MITM attack a second handshake announcing SSLv3 and setting TLS_FALLBACK_SCSV option than the server knows that the client supports something better than SSLv3 and quits the handshake. Best regards, Richard On Fri, Oct 24, 2014 at 9:30 AM, Jakob Bohm jb-open...@wisemo.com mailto:jb-open...@wisemo.com wrote: On 24/10/2014 18:19, Aditya Kumar wrote: Thanks Jakob for correcting my understanding. In short, can I conclude the following about FALLBACK flag. 1. Whenever client is sending the FALLBACK flag in its request, an updated Server will interpret it that this client supports a higher version but since that higher version protocol request was refused, its trying to connect using a lower version protocol. 2. The FALLBACK flag should only be set to communicate to those extremely rare old SSLv3 servers which completely fail to accept a request for (SSLv3 or TLSv1+, the best client have). In that case, first client should attempt to connect with SSLAUTONEGOTIATE and if it fails, then connect with SSLV3 FALLBACK enabled. Much simpler: The FALLBACK flag should be set only to communicate that the client has activated its manual fall back code (if any). If the client doesn't contain manual fallback code, it doesn't need to do anything. 3. Points 2 holds true even for the cases where clients connecting using TLS 1.2 fail and then client need to connect using TLS 1.1, TLS1.0 or SSLV3.0. Then client should attempt the next connections using FALLBACK flag set. Yes, SSLv3 is just an example, which happens to be important right now because of poodle. Hope this will clear all the confusions. -Aditya On Fri, Oct 24, 2014 at 5:35 PM, Jakob Bohm jb-open...@wisemo.com mailto:jb-open...@wisemo.comwrote: On 24/10/2014 13:33, Aditya Kumar wrote: Hi All, Thanks for your detailed responses, specially Florian Weimer and Matt Caswell. For the benefit of everyone and me, I am summarizing the thoughts which I have understood through all your replies. Please correct me wherever I am wrong. To summarize: 1. Best way to prevent POODLE attack is to disable SSLV3 on both client and server side. 2. If for some reason, you cannot disable SSLv3 on server side even if Server support TLS 1.0 or higher(e.g server having SSLV23 set), Server definitely need to be patched to prevent fallback. Once server is patched, it will prevent updated clients from fallback attack. 3. After server is patched with OpenSSL FALLBACK flag fix, Server’s behavior will not change for the clients which do not send FALLBACK flag in their clienthello request. Server will continue to work with older client as usual. Only if an updated client sends FALLBACK flag into its clienthello request, server will be able to prevent fallback. 4. If for some reason, client has to keep SSLV3 enable even if it supports TLS 1.0 or higher version, client need to patch itself and set FALLBACK flag so that it does not come under fallback attack. WRONG, See below 5. Clients should never set protocol as SSLV23 to support both SSL3.0 and TLS Servers. Clients should always explicitly first try to connect using its highest supported version(TLS1.0 or higher) and if the server rejects the connection, then clients should explicitly try to connect using next supported lower version protocol. WRONG, If client simply calls the SSL23_ (aka SSLAUTONEGOTIATE_) with options to allow both SSLv3 and higher TLSvX.XX, it is already secure and will never need to send the fallback flag. 6. While connecting to server using higher
Re: OS/390 z/OS Help Needed
Am 08.07.2014 18:10, schrieb T. Travers: I am new to this forum so please excuse me if I do not do this right. I am working on a z/OS 1.13 system aka OS/390 aka MVS. We have the need to parse X509 certificates. We were using an older version, 0.9.6a, but found that it did not interpret new signing algorithms correctly. I pulled down 1.0.1h and after a few known glitches, I was able to compile it. It does what I need in the sense that it now interprets the newer algorithms but it fails on the certificate time fields. I am doing this command opensslx509 -noout-in /certfile/ -text and I get this output (serial number and signer removed): Certificate: Data: Version: 3 (0x2) Serial Number: Signature Algorithm: sha256WithRSAEncryption Issuer: C=GB, ... Validity Not Before: Bad time value I am not sure how to proceed. If anyone could instruct me or direct me, I would appreciate it. Tim T. Iirc some parts of the ASN1 code was rewritten in the 0.9.7 line (with EBCDIC specific parts being commented out). Please look at bug tracker entry #843 (http://rt.openssl.org/Ticket/Display.html?id=843), which contains a patch set for 0.9.7c and 0.9.7j. Unfortunately i still found not enough time for submitting a correspondig patch for the 1.0.x lines, but maybe the crypto/asn1/* files haven't changed too much for the patches still being useful. Ciao, Richard __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: State of EBCDIC support in OpenSSL
Hello, in the request tracker under item #843 there are patches for 0.9.7c (created and tested on Fujitsu BS2000) and 0.9.7j (updated by Jeremy Grieshop for z/OS). Because i saw no actions to incorporate the patches into the official sources in the last ten years i saved afterwards the work to commit our patches for newer OpenSSL versions. If there is interest i can provide patches for lines 0.9.8, 1.0.0 and 1.0.1 too; it will probably take some days because i have first to look at the patches and maybe remove some non-EBCDIC related parts. Best regards, Richard Am 29.04.2014 13:52, schrieb mclellan, dave: We are active and continuing users of the z/OS port of OpenSSL, have just rebuilt 1.0.1c without heartbeats on a maintenance stream and are upgrading to 1.0.g on a future release stream. Just as example of staying current on z/OS. We use z/OS on the server side only, and generates server certs from a Windows machine, and transfer the certs to USS using binary FTP. The server does not require a client cert since we couldn't get that working and have never had time to look into it. We don't use the openssl CLI on z/OS. We have even considered the port for Fujitsu BS2000 but don't have a business priority for it. All this to say that we sure hope that z/OS and OpenSSL continue to be real, and I'm glad to have read Tim's response. +-+-+-+-+-+-+-+-+- Dave McLellan, VMAX Software Engineering, EMC Corporation, 176 South St. Mail Stop 176-V1 1/P-36, Hopkinton, MA 01749 Office:508-249-1257, Mobile: 978-500-2546, dave.mclel...@emc.com +-+-+-+-+-+-+-+-+- -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Stephan Mühlstrasser Sent: Tuesday, April 29, 2014 4:48 AM To: Tim Hudson; openssl-users@openssl.org Subject: Re: State of EBCDIC support in OpenSSL Am 29.04.14 10:28, schrieb Tim Hudson: Bug reports on EBCDIC with patches are definitely interesting as there is an active community of OpenSSL z/OS users - at the very least the other users will benefit from any work you have already done. I can provide bug reports, but at the moment I cannot promise that I can come up with corresponding patches as well. I did some research in the OpenSSL mailing list archives, and from that I have the impression that there's little activity from OpenSSL z/OS users over the last few years. Are there other places where you see the active community of OpenSSL z/OS users? For the broader context I think you'll find the issue for handling such platforms will usually be the typical one of regular platform access. Checking, adjusting, and confirming patches which are platform specific that are non-trivial basically requires access to the platform. One thing to consider is if you (or anyone else) is able to provide permanent (or semi-permanent) access (via ssh) to a z/OS platform with USS installed that places the user into a standard shell environment with the compilers accessible. I'm sorry, but I can't help with platform access, as we only have a z/OS development system for porting our software, not even a real zSeries machine. I would expect that IBM itself should be interested in a working OpenSSL port for zSeries. We have a very old version of OpenSSL on our system that we downloaded from the IBM website in the past. This version is for example able to print out certificates correctly. Today the IBM website about open source software available for z/OS point to openssl.org for getting OpenSSL: http://www-03.ibm.com/systems/z/os/zos/features/unix/bpxa1ty1.html The free unsupported version of OpenSSL previously offered here is no longer available. Instead, we refer you to the functionally equivalent version available from the official OpenSSL project website. If someone from IBM is reading this, please consider the request by Tim for access to a z/OS platform. Stephan __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Openssl/SMime Utility failed to encrypt the large file (1.5MB) on HPUX Machine
Am 03.10.2013 14:32, schrieb Puneet Khunteta: Hello, I have later found that the fail behavior may be due to the insufficient memory available for the target device . I have seen that -stream option is added in smime application in openssl version 1.0.0 . 1.) Can i have the access to the change set for this particular functionality only ( -stream functionality ) ? I saw their are other bugs/issue change set also in openssl 1.0.0 Vs openssl 0.9.8n ? I need only this particular change set because i am running on 0.9.8a version. 2.) Can i know what is the fixed stream size now , if any? Do you mean the output size? If yes, for bigger mails the size increase should come mainly from base64 encoding, that means size increasing by a factor of 4/3. 3.) Is it true that before -stream option entire in data and out data is loaded in memory itself ? Yes. Regards PK On Wed, Oct 2, 2013 at 12:58 PM, Puneet Khunteta khunteta.pun...@gmail.com mailto:khunteta.pun...@gmail.com wrote: Hello Guys, I am a newbie to this forum though I worked with the openssl code little while. I have faced an issue while performing encryption on a HPUX target machine to get a pkcs7 format output. I was trying the following command to perform the encryption using s/mime utility : openssl smime -encrypt -binary -in XYZ.eml -out XYZ-Enc.eml -aes256 Encrypt.cer where Encrypt.cer is in PEM format This utility works will if we have the input file data less than and around 1.5 MB . But fails if it exceed with 1.5 MB. In Fail Scenario, I have noticed that out file is encrypted and i can also decrypt it but the decrypt data is not matched with the in file data. Also i have noticed that in failure case out file size is always less than input file size. On the other hand, same utility works on windows target with large file also. I have few questions as following : 1.) Do smime utility have any such limitation of size on HPUX target ? 2.) How can i find out that how much size of data is actually get encrypted ? Regards -PK __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: using TRNG via /dev/random
Am 23.09.2013 21:59, schrieb starlight.201...@binnacle.cx: At 20:27 9/23/2013 +0200, Richard Könning wrote: /dev/random is a PRNG which blocks when the (crude) entropy estimation of the entropy pool falls below a limit. Besides this there are afaik no big differences between /dev/random and /dev/urandom. In the sense that all TRNG outputs are run through various algorithms that mix and whiten the data to assure uniform statistical distribution, all TRNGs could be called PRNGs. However the crucial difference is that TRNG post-filter output is irreproducible where a pseudo random number generator will predictably generate identical streams of output given the same seed. So Intel's RDRAND is a PRNG in the sense you seem to be invoking. [...] /dev/urandom (in newer kernels) continually re-seeds itself from the common entropy pool but will apply TRNG when demand exceeds supply. My desire is to experiment According to my knowledge /dev/random and /dev/urandom work almost identical between two consecutive reseeding operations, the only difference being that /dev/random blocks when the entropy counter falls below a limit thus limiting the delivery of random bytes between reseeding operations (maybe in newer kernels there is some separation of the entropy pool between the two devices, in older kernels they were iirc using the same pool). That means, as long as /dev/random doesn't block it operates in the same way as /dev/urandom and probably gives the same random numbers with a given entropy pool content. with having 'openssl' rely on the better quality /dev/random source (enhanced by a higher-volume input such as from a TPM or RDRAND) at the cost of occasional millisecond time-scale delays. From random.c: The two other interfaces are two character devices /dev/random and /dev/urandom. /dev/random is suitable for use when very high quality randomness is desired (for example, for key generation or one-time pads), as it will only return a maximum of the number of bits of randomness (as estimated by the random number generator) contained in the entropy pool. The /dev/urandom device does not have this limit, and will return as many bytes as are requested. As more and more random bytes are requested without giving time for the entropy pool to recharge, this will result in random numbers that are merely cryptographically strong. For many applications, however, this is acceptable. If you can convince the kernel developers that the above statement is incorrect and have a patch accepted to modify the text, I'll abandon my exploration of employing /dev/random. Until then I find the random.c comments authoritative. The random.c comments say the same as i wrote above: /dev/random blocks when the (crude) entropy counter falls below a specific limit, /dev/urandom not. I certainly can an will dig into the code. Merely posted here in the hope that someone was familiar with the behavior of 'openssl' in the face of blocked requests for random bytes. Well, when /dev/random is used and it blocks, then the initialization of the OpenSSL PRNG will block too. Ciao, Richard __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: using TRNG via /dev/random
Am 24.09.2013 02:05, schrieb starlight.201...@binnacle.cx: At 12:59 9/23/2013 -0700, Michael Sierchio wrote: I'll repeat myself - the fact that the /dev/random implementation you're using blocks is a serious design flaw. Convince Linus, the GPG developers et al.--not me. No one has to convince Linus, every one is free to use /dev/urandom instead of /dev/random. Ciao, Richard __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: using TRNG via /dev/random
Am 22.09.2013 19:27, schrieb starlight.201...@binnacle.cx: No /dev/urandom is a PRNG. /dev/random is a TRNG. Read the code https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/char/random.c?id=272b98c6455f00884f0350f775c5342358ebb73f /dev/random is a PRNG which blocks when the (crude) entropy estimation of the entropy pool falls below a limit. Besides this there are afaik no big differences between /dev/random and /dev/urandom. Best regards, Richard __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: possible Bug in OpenSSL - rfc 3161 - TSA service
Am 11.03.2013 13:01, schrieb kap...@mizera.cz: P.S: is this forum monitored by developers of openssl or should I report it in devel forum? At least Stephen Henson answers regularily in this mailing list (as you can see by looking into a couple of threads), therefore i would stay in this list until it is clear that there is a problem with OpenSSL itself. Best regards, Richard __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: I can't believe how much this sucks
Am 19.11.2012 15:45, schrieb John Zavgren: So, what is a list of easy-to-follow code examples? Here are some suggestions: 1.) read private key and a message from a file: encrypt message with private key, write encrypted buffer to (another) file. 2.) read cert and private key, read file, compute signature, etc. 3.) read file, read signature, read ca certs, validate signature. 4.) Example 3 + check CRL. 5.) Example 3 + check with OCSP responder. ??? I'm sure there are a LOT of CA related examples that would help, because I find the creation of a CA to be one of the more painful exercises. Well, many of these things are covered at least partially by the OpenSSL book from Viega et al. The book is somewhat outdated/incomplete but still my first reference when i have to implement a new cryptography related task with OpenSSL. Best regards, Richard __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Passing TLS sessions between programs
Am 03.11.2012 15:26, schrieb Frediano Ziglio: Hi, I'm searching for a way to pass a TLS session between two programs under Unix. I can use unix sockets to send the file descriptor but I don't know how to request to OpenSSL crypto information (like algorithm used and key) in order to pass to the other process. Is there a way to do it ? Use http://www.openssl.org/docs/ssl/SSL_get_session.html as a starting point for reading. Best regards, Richard __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Disabling kEDH on webservers for scaling?
Hello, the kEDH set of cipher suites provide so called perfect forward secrecy, for a description of this term see e.g. http://en.wikipedia.org/wiki/Perfect_forward_secrecy. Ciao, Richard Am 26.04.2012 13:23, schrieb Jack Bauer: We are currently experiencing some scaling problems on our webservers (nginx). They are terminating SSL connections and passing the requests to backend servers. After some testing, it appears that scaling is no problem, when the kEDH cipher is disabled by passing !kEDH to openssl. Can someone please explain, what disabling kEDH exactly means and tell if there are any caveats concerning client/end-point security? Thanks. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Difference in Private Key?
Am 19.04.2012 14:05, schrieb Daniel Doron: Hi, I have noticed the following command sequence generates Private Key files with different _Header_. Is there a reason for this?? You will A quick look into the source gave me no strong hint whether this is intended, is a bug or is sloppiness not qualifying as a bug. But some checks in the code on the prefix to PRIVATE KEY may be a hint that it may be handled as a bug at least in some situations... Anyway, try to insert RSA before PRIVATE KEY and check whether this makes your embedded system happy. also notice that the character count is different… This is to be expected already from the specifics of the ASN.1 encoding, so this alone is not a hint that something is wrong. A call of openssl rsa -in key file -noout -text showed no fundamental difference between your two keys. The first private key cause our embedded system (not Linux, proprietary) to choke while the second one was went smoothly. Please check with the added RSA string, if this makes your embedded system happy than the only question is, whether this is a bug in OpenSSL or in the embedded system, the latter being to strict with what it accepts. Ciao, Richard __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: RES: Random number generator
Am 05.04.2012 13:35, schrieb Leonardo: I’d like to add some question about this. What kind of RNG is implemented? Linear Congruential generator? No. Is it another more sophisticated? Yes. For more information see the rand man page. Ciao, Richard __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: weak key check?
Am 16.02.2012 12:17, schrieb Jakob Bohm: 2. Creating primes starts with high quality random numbers, such that there are a gigantic number of possible primes. If done correctly (like in current OpenSSL versions), the chance of choosing the same prime as somebody else is extremely low (again, I hope someone else on this list can come up with the numbers for general enlightenment). Well, seeding the PRNG correctly seems not to be a trivial task, see e.g. http://eprint.iacr.org/2012/064.pdf and https://freedom-to-tinker.com/blog/nadiah/new-research-theres-no-need-panic-over-factorable-keys-just-mind-your-ps-and-qs. Ciao, Richard __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Question on OpenSSL encryption
Am 09.01.2012 13:10, schrieb Ashok C: Hi, In addition to the online material, are there any good books which we can refer to understand openSSL better? Both conceptually as well as from the API/code perspective. We hear of the Network Security with OpenSSL by John Viega as one good reference. But it was published in 2002. Any good new books which can be used? Well, the questions of the original poster weren't OpenSSL specific, but targeted SSL/TLS in general, for this Eric Rescorla's book SSL and TLS: Building and Designing Secure Systems is the better book. Sadly being from the year 2000 it is somewhat outdated too, but nevertheless a good introduction to SSL/TLS. For a description of the OpenSSL API afaik the book from Viega et al. is still the most detailed book, despite being somewhat outdated. For newer versions of TLS (i.e. 1.1 and beyond) one should check newer TLS books, e.g. the ones from Joshua Davies or Rolf Oppliger. Until now i had none of the two books in my hands so i can't you tell more about the books, but maybe a visit at Amazon or similar book traders will give you at least a detailed content description. Ciao, Richard __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: SSL session ID vs session ticket
Am 27.10.2011 14:09, schrieb Matthias Meixner: Hello! When upgrading to version 0.9.8r my system stopped supporting session resumption. It looks like session tickets are the reason for this. I was using some external session cache to support session resumption on a cluster of servers where it should be possible that each server in the cluster can resume the SSL connection. With the upgrade to version 0.9.8r this stopped working Try using something like SSL_CTX_set_options(ssl_ctx, SSL_OP_NO_TICKET); Ciao, Richard __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Regarding cipher suites in SSLv3.
Am 12.10.2011 15:29, schrieb nilesh: Hi, I am writing some code for decryption of https data. Currently I have planned to support SSLv3 with AES, 3DES and RC4 algorithms only. Below are the cipher suites in SSLv3. I am looking for information on which of these suites are commonly used. SSLv3 implements all of them, but I have seen only few of them get negotiated frequently (it also depends upon how ssl.conf is modified, for apache/httpd. But usually without touching the config file, which of them are popularly used?). I haven't done extensive test, but after setting up apache on 2-3 different machines, I never saw 'TLS_KRB5_WITH...' or 'TLS_DH_anon_..' being negotiated. Any idea? Well, using a Kerberos cipher suite makes only sense when you are in an environment with running Kerberos servers for authentication. If you do not know what Kerberos is you probably don't need the Kerberos cipher suites. Anonymous cipher suites are susceptible to MITM attacks, so normally you don't want use them. And the EXPORT cipher suites you don't want use neither because they use very short encryption keys. With this your list will reduce to TLS_RSA_WITH_RC4_128_MD5 TLS_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA TLS_DHE_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_256_CBC_SHA TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA TLS_DHE_DSS_WITH_AES_128_CBC_SHA TLS_DHE_DSS_WITH_AES_256_CBC_SHA Best regards, Richard __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: TLS false start support on Openssl
Am 06.10.2011 23:28, schrieb Ritesh Rekhi: Does openssl support TLS false start http://tools.ietf.org/html/draft-bmoeller-tls-falsestart-00 ? I cite the last section of this draft: At the time of writing, the authors are not aware of any deployed TLS implementation that is not False Start compatible (with one single host still pending investigation). However, if an implementation uses a strategy of receiving as many bytes as available from the underlying transport during the handshake (expecting to find only handshake messages), achieving False Start compatibility would likely require special care. One of the authors being member of the OpenSSL team i think that he has investigated the OpenSSL case. If Openssl supports TLS false start how can I use it with s_client ? When there is not already an appropriate option (i didn't check), you have to add corresponding code to s_client. Ciao, Richard __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
