Re: Fedora/Redhat and perfect forward secrecy
On 09/07/2013 12:52 AM, Gregory Maxwell wrote: Regardless, I think that argument would be an ignorant one: Approximately no one runs non-ECDH PFS on the web: it's insanely slow and it breaks clients. Hmm. Isn't non-ECDH PFS just straight integer (mod N) Diffie-Hellman? And that's what is insanely slow? Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora/Redhat and perfect forward secrecy
On 09/09/2013 11:58 AM, Andrew Haley wrote: On 09/07/2013 12:52 AM, Gregory Maxwell wrote: Regardless, I think that argument would be an ignorant one: Approximately no one runs non-ECDH PFS on the web: it's insanely slow and it breaks clients. Hmm. Isn't non-ECDH PFS just straight integer (mod N) Diffie-Hellman? Yes, it is. And that's what is insanely slow? I don't get it, either. -- Florian Weimer / Red Hat Product Security Team -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora/Redhat and perfect forward secrecy
Am 09.09.2013 12:55, schrieb Florian Weimer: On 09/09/2013 11:58 AM, Andrew Haley wrote: On 09/07/2013 12:52 AM, Gregory Maxwell wrote: Regardless, I think that argument would be an ignorant one: Approximately no one runs non-ECDH PFS on the web: it's insanely slow and it breaks clients. Hmm. Isn't non-ECDH PFS just straight integer (mod N) Diffie-Hellman? Yes, it is. And that's what is insanely slow? I don't get it, either google dhe versus ecdhe performance http://vincent.bernat.im/en/blog/2011-ssl-perfect-forward-secrecy.html Let’s focus on the server part. Enabling DHE-RSA-AES128-SHA cipher suite hinders the performance of TLS handshakes by a factor of 3. Using ECDHE-RSA-AES128-SHA instead only adds an overhead of 27%. However, if we use the 64bit optimized version, the cost is only 15% is that enough to understand why nobody on this world is using DHE and so your Current Fedora supports perfect forward secrecy just fine is *far* away from the reality? it does not help much support forward secrecy in a way *nobody* else on this planet is supporting it and so you repsonse below is uneducated - period Original-Nachricht Betreff: Re: Fedora/Redhat and perfect forward secrecy Datum: Mon, 26 Aug 2013 11:07:29 +0200 Von: Florian Weimer fwei...@redhat.com An: Development discussions related to Fedora devel@lists.fedoraproject.org Kopie (CC): Reindl Harald h.rei...@thelounge.net, Mailing-List fedora-users us...@lists.fedoraproject.org On 08/24/2013 11:38 AM, Reindl Harald wrote: https://bugzilla.redhat.com/show_bug.cgi?id=319901 looks like Redhat based systems are the only remaining which does not support EECDHE which is a shame these days in context of PRISM and more and more Ciphers are going to be unuseable (BEAST/CRIME weakness) Current Fedora supports perfect forward secrecy just fine. It's just that web server operators routinely refuse to offer it. (The situation is different with mail servers.) Operational benefits look rather marginal to me. It may discourage interested parties from requesting server private keys, but even that isn't assured. signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora/Redhat and perfect forward secrecy
On Mon, 9 Sep 2013, Reindl Harald wrote: I don't get it, either google dhe versus ecdhe performance http://vincent.bernat.im/en/blog/2011-ssl-perfect-forward-secrecy.html Let’s focus on the server part. Enabling DHE-RSA-AES128-SHA cipher suite hinders the performance of TLS handshakes by a factor of 3. Using ECDHE-RSA-AES128-SHA instead only adds an overhead of 27%. However, if we use the 64bit optimized version, the cost is only 15% is that enough to understand why nobody on this world is using DHE and so your Current Fedora supports perfect forward secrecy just fine is *far* away from the reality? Not for me. I thought TLS was latency bound. The above factor 3 does not state whether TLS client/server were in the same LAN (or even VMs on the same host). For the client, clearly CPU is not the limiting factor. For regular TLS servers, this should also not matter. For fully loaded TLS servers or TLS accelerators, the factor 3 on the CPU load will matter, but we're talking clusters of machines here. Dropping in a few extra machines shouldn't be that hard to give your patent-encumbered endusers PFS. it does not help much support forward secrecy in a way *nobody* else on this planet is supporting it and so you repsonse below is uneducated - period Ignoring the obvious legal (and now potential backdoor) problems with ECC is also not very educated. Paul Original-Nachricht Betreff: Re: Fedora/Redhat and perfect forward secrecy Datum: Mon, 26 Aug 2013 11:07:29 +0200 Von: Florian Weimer fwei...@redhat.com An: Development discussions related to Fedora devel@lists.fedoraproject.org Kopie (CC): Reindl Harald h.rei...@thelounge.net, Mailing-List fedora-users us...@lists.fedoraproject.org On 08/24/2013 11:38 AM, Reindl Harald wrote: https://bugzilla.redhat.com/show_bug.cgi?id=319901 looks like Redhat based systems are the only remaining which does not support EECDHE which is a shame these days in context of PRISM and more and more Ciphers are going to be unuseable (BEAST/CRIME weakness) Current Fedora supports perfect forward secrecy just fine. It's just that web server operators routinely refuse to offer it. (The situation is different with mail servers.) Operational benefits look rather marginal to me. It may discourage interested parties from requesting server private keys, but even that isn't assured. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora/Redhat and perfect forward secrecy
Am 09.09.2013 18:12, schrieb Paul Wouters: On Mon, 9 Sep 2013, Reindl Harald wrote: I don't get it, either google dhe versus ecdhe performance http://vincent.bernat.im/en/blog/2011-ssl-perfect-forward-secrecy.html Let’s focus on the server part. Enabling DHE-RSA-AES128-SHA cipher suite hinders the performance of TLS handshakes by a factor of 3. Using ECDHE-RSA-AES128-SHA instead only adds an overhead of 27%. However, if we use the 64bit optimized version, the cost is only 15% is that enough to understand why nobody on this world is using DHE and so your Current Fedora supports perfect forward secrecy just fine is *far* away from the reality? Not for me. I thought TLS was latency bound. The above factor 3 does not state whether TLS client/server were in the same LAN (or even VMs on the same host). it does not matter, the world measures CPU load here For the client, clearly CPU is not the limiting factor if you stay on topic you realize that this does not matter you can't do PFS to *any* major website these days For regular TLS servers, this should also not matter. For fully loaded TLS servers or TLS accelerators, the factor 3 on the CPU load will matter, but we're talking clusters of machines here. Dropping in a few extra machines shouldn't be that hard to give your patent-encumbered endusers PFS. *you* are talking clusters here it does not help much support forward secrecy in a way *nobody* else on this planet is supporting it and so you repsonse below is uneducated - period Ignoring the obvious legal (and now potential backdoor) problems with ECC is also not very educated we are speaking about the real world, not about therory *you can't* do PFS to *any* relevant target because nobody offers negotiation with DHE - so stay on topic and as long nothing is *proven* ignore it while it *is* proven that PFS doe snot work with Redhat/Fedora systems to the rest of the world signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora/Redhat and perfect forward secrecy
On Mon, Sep 9, 2013 at 9:12 AM, Paul Wouters p...@nohats.ca wrote: For the client, clearly CPU is not the limiting factor. For regular TLS servers, this should also not matter. For fully loaded TLS servers or TLS accelerators, the factor 3 on the CPU load will matter, but we're talking clusters of machines here. Dropping in a few extra machines shouldn't be that hard to give your patent-encumbered endusers PFS. The difference between DHE and ECDH in TLS is a difference of supporting supporting about 3,000 connections per second and supporting something like 800 connections per second (somewhat vague numbers, opeenssl speed won't bench DH apparently, it's somewhat slower than RSA encrypt due to the exponentiation by large secret values). And this is comparing apples and oranges 256bit ECDSA (conjectured security involving a best attack 2^128) against DH-1024 (only 80 bit conjectured security). Comparing with DH-1024 is sort of silly because people do not consider 80 bit security adequate anymore. The comparison with 3072 bit DH is down to more like 200 connections per second. But again, and sorry to reiterate but it seems to be have been missed: ~No one actually supports the old DHE PFE, and offering it breaks some clients. So regardless of the speed concerns, a choice to not support ECDH is a choice to not have PFS at all, at least on public facing webservers. Ignoring the obvious legal (and now potential backdoor) problems with ECC is also not very educated. I am certainly not ignoring legal concerns. While there are some patented EC cryptographic techniques, the basic infrastructure including ECDH over prime fields was first published back in 1984 and is not patentable. The IETF has published an extensive RFC covering the foundations of ECC which carefully shows to-old-to-be-patentable direct citations: http://tools.ietf.org/html/rfc6090 If Redhat is aware of a specific patent concern here, they're keeping it secret from the public. The continued claims that there are legal issues here behind basic support really don't make a lot of sense, especially considering the functionality in RHEL. (I would also note that the support in RHEL somewhat oddly support _only_ the parameters from the NSA, which doesn't quite play into the expressed concern about backdoors) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora/Redhat and perfect forward secrecy
On Mon, 9 Sep 2013, Gregory Maxwell wrote: I am certainly not ignoring legal concerns. While there are some patented EC cryptographic techniques, the basic infrastructure including ECDH over prime fields was first published back in 1984 and is not patentable. The IETF has published an extensive RFC covering the foundations of ECC which carefully shows to-old-to-be-patentable direct citations: http://tools.ietf.org/html/rfc6090 If Redhat is aware of a specific patent concern here, they're keeping it secret from the public. The continued claims that there are legal issues here behind basic support really don't make a lot of sense, especially considering the functionality in RHEL. [not speaking for Red Hat] You seem to believe only valid legal claims can put Red Hat in court. (I would also note that the support in RHEL somewhat oddly support _only_ the parameters from the NSA, which doesn't quite play into the expressed concern about backdoors) [again not speaking for Red Hat, no idea of any arrangements] I can come up with various commercial non-conspiracy theories for this. For example, who pays the lawyers when a patent troll arrives. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora/Redhat and perfect forward secrecy
On Mon, Sep 9, 2013 at 11:46 AM, Paul Wouters p...@nohats.ca wrote: [not speaking for Red Hat] You seem to believe only valid legal claims can put Red Hat in court. Of course not. Though I'm not aware of anyone making any claims at all over basic non-specially optimized ECDH on prime fields. Perhaps RedHat is, though if certicom/rim is out patent trolling on the basic stuff it would be a shame to keep it a secret: They should take the goodwill loss they deserve if they're going around claiming to own techniques published in the mid 80s. You're going to have a lot of software to remove if the _possibility_ of someone putting RedHat in court is the bar here. There are a _LOT_ more patents on compilers than on elliptic curve cryptography. Or just patents on simple arithmetic optimizations, lets see US6073150 assigned to Sun. This one patents computing the absolute value of a signed number using masking by sign extension: E.g. Set mask = x(sizeof(x)*sizeof(char)-1); absx = (x^mask)-mask. Oh looky looky, GCC in Fedora 19 on x86_64 compiles int x; x = abs(x); to this: sarl$31, %eax xorl%eax, -4(%rbp) subl%eax, -4(%rbp) Good thing nothing in Fedora uses abs() and that Sun's patent's would never be held by a potentially hostile company so you don't have to depend on the fact that this technique was published eons before the patent (http://web.archive.org/web/19961201174141/www.x86.org/ftp/articles/pentopt/PENTOPT.TXT), since that the invalidity of the claim can't be ensured to keep RedHat out of court. ... And this is an example where we actually do the stuff that is patented. I do not believe there are any granted but invalid patents that would preclude using basic ECDH over prime fields. Maybe there are and RedHat has heard of some, but if so the world would certainly like to know that someone actual had a concrete risk here and this wasn't someone just pattern matching ECC = Patents ZOMG! in a way that they don't go Compilers = Patents ZOMG!. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora/Redhat and perfect forward secrecy
| From: Reindl Harald h.rei...@thelounge.net | Date: Sat, 24 Aug 2013 11:38:21 +0200 | https://bugzilla.redhat.com/show_bug.cgi?id=3D319901 | | looks like Redhat based systems are the only remaining | which does not support EECDHE which is a shame these | days in context of PRISM and more and more Ciphers | are going to be unuseable (BEAST/CRIME weakness) It might be the case that the NSA has their fingers in these ECC standards. Here's a Schneier article worth reading: http://www.theguardian.com/world/2013/sep/05/nsa-how-to-remain-secure-surveillance In it, he recommends (among many other things): Prefer conventional discrete-log-based systems over elliptic-curve systems; the latter have constants that the NSA influences when they can. It could be (by accident) that Fedora is more secure due to patents! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora/Redhat and perfect forward secrecy
On Fri, Sep 6, 2013 at 2:31 PM, D. Hugh Redelmeier h...@mimosa.com wrote: | From: Reindl Harald h.rei...@thelounge.net | Date: Sat, 24 Aug 2013 11:38:21 +0200 | https://bugzilla.redhat.com/show_bug.cgi?id=3D319901 | | looks like Redhat based systems are the only remaining | which does not support EECDHE which is a shame these | days in context of PRISM and more and more Ciphers | are going to be unuseable (BEAST/CRIME weakness) It might be the case that the NSA has their fingers in these ECC standards. Here's a Schneier article worth reading: http://www.theguardian.com/world/2013/sep/05/nsa-how-to-remain-secure-surveillance In it, he recommends (among many other things): Prefer conventional discrete-log-based systems over elliptic-curve systems; the latter have constants that the NSA influences when they can. It could be (by accident) that Fedora is more secure due to patents! The P-256r curve commonly used for ECDH the web has it's parameters generated by a nothing-up-my-sleeve CSPRNG approach. I doubt Bruce was speaking of that... it he was, I think thats a pretty audacious claim that requires some justification. Regardless, I think that argument would be an ignorant one: Approximately no one runs non-ECDH PFS on the web: it's insanely slow and it breaks clients. The choice is not between ECDH and RSA based PFS, the choice is between ECDH and no PFS at all. Right now Fedora webservers have no PFS at all. This can not be argued to be an improvement. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora/Redhat and perfect forward secrecy
On 08/24/2013 11:38 AM, Reindl Harald wrote: https://bugzilla.redhat.com/show_bug.cgi?id=319901 looks like Redhat based systems are the only remaining which does not support EECDHE which is a shame these days in context of PRISM and more and more Ciphers are going to be unuseable (BEAST/CRIME weakness) Current Fedora supports perfect forward secrecy just fine. It's just that web server operators routinely refuse to offer it. (The situation is different with mail servers.) Operational benefits look rather marginal to me. It may discourage interested parties from requesting server private keys, but even that isn't assured. It does not help against server operators which provide third parties with cleartext copies of transmissions, obviously. Perfect forward secrecy is totally unrelated to padding oracles and compression leaks. Fedora already provides several countermeasures against those, such as TLS 1.2 support and disabling compression. These issues require active attacks and would leave traces in sufficiently detailed log files, too. -- Florian Weimer / Red Hat Product Security Team -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora/Redhat and perfect forward secrecy
On Mon, Aug 26, 2013 at 11:07:29AM +0200, Florian Weimer wrote: On 08/24/2013 11:38 AM, Reindl Harald wrote: https://bugzilla.redhat.com/show_bug.cgi?id=319901 looks like Redhat based systems are the only remaining which does not support EECDHE which is a shame these days in context of PRISM and more and more Ciphers are going to be unuseable (BEAST/CRIME weakness) Current Fedora supports perfect forward secrecy just fine. Just fine -- assuming one ignores the 4-5x performance penalty of DH (vs. non-PFS/ECDHE), and also ignore IE and Safari as clients ? It's just that web server operators routinely refuse to offer it. The perf penalty of DH-RSA seems a bit high, and web server operators are likely fighting anything that is likely to introduce latency.. (The situation is different with mail servers.) Operational benefits look rather marginal to me. It may discourage interested parties from requesting server private keys, but even that isn't assured. It does not help against server operators which provide third parties with cleartext copies of transmissions, obviously. It helps against broad prism-style interception of all traffic, with the intention of decrypting at some later point. -jf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora/Redhat and perfect forward secrecy
Am 26.08.2013 11:07, schrieb Florian Weimer: On 08/24/2013 11:38 AM, Reindl Harald wrote: https://bugzilla.redhat.com/show_bug.cgi?id=319901 looks like Redhat based systems are the only remaining which does not support EECDHE which is a shame these days in context of PRISM and more and more Ciphers are going to be unuseable (BEAST/CRIME weakness) Current Fedora supports perfect forward secrecy just fine it does *not* yes it does in theory It's just that web server operators routinely refuse to offer it. cause and effect because Fedora does *not* support Ciphers without large performance impacts in reality without ECDHE you have no way go to https://www.ssllabs.com/ssltest/ and look at the client-handshakes practically no client is using PFS without ECDHE that's the truth if it comes to PFS and Redhat/Fedora http://www.internetstaff.com/roller/blog/entry/enable_elliptical_curve_diffie_hellman http://www.theverge.com/2013/6/26/4468050/facebook-follows-google-with-tough-encryption-standard signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora/Redhat and perfect forward secrecy
Am 26.08.2013 13:26, schrieb Jan-Frode Myklebust: On Mon, Aug 26, 2013 at 11:07:29AM +0200, Florian Weimer wrote: On 08/24/2013 11:38 AM, Reindl Harald wrote: https://bugzilla.redhat.com/show_bug.cgi?id=319901 looks like Redhat based systems are the only remaining which does not support EECDHE which is a shame these days in context of PRISM and more and more Ciphers are going to be unuseable (BEAST/CRIME weakness) Current Fedora supports perfect forward secrecy just fine. Just fine -- assuming one ignores the 4-5x performance penalty of DH (vs. non-PFS/ECDHE), and also ignore IE and Safari as clients? in fact Safari is nearly the *one and only* client using PFS on a Fedora Server - expect you configure ciphers in a way BEAST attack becomes a vector and you are failing *any* security audit because of this besides this *you are unable* to use FPS if you connect to Google/Facebook with your webbrowser as well for SMTP-STARTTLS because they use ECDHE and *not* DHE so in the real world saying Fedora supports perfect forward secrecy just fine is somehow clueless even if someone is now saying that i am unpolite again but that is the truth and whoever states that this is not true has to prove it https://www.ssllabs.com/ssltest/ i wasted *6 hours* of my lifetime coming to the result it is not possible with Fedora _ actually these clients are the only using DHE and without FF/MSIE/Opera you can say practiacally *nobody* is using it Chrome 29 / Win 7 TLS 1.2 TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x6b) FS OpenSSL 1.0.1e TLS 1.2TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x9f) FS Safari 6 / iOS 6.0.1 TLS 1.2 TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x6b) FS Safari 7 / OS X 10.9 TLS 1.2 TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x6b) FS _ Handshake Simulation Chrome 29 / Win 7 TLS 1.2 TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x6b) FS 256 Firefox 10.0.12 ESR / Win 7 TLS 1.0 SSL_RSA_WITH_RC4_128_SHA (0x5) No FS 128 Firefox 17.0.7 ESR / Win 7 TLS 1.0 SSL_RSA_WITH_RC4_128_SHA (0x5) No FS 128 Firefox 21 / Fedora 19 TLS 1.0 SSL_RSA_WITH_RC4_128_SHA (0x5) No FS 128 Firefox 22 / Win 7 TLS 1.0 SSL_RSA_WITH_RC4_128_SHA (0x5) No FS 128 IE 6 / XP No FS * Fail** IE 7 / VistaTLS 1.0 SSL_RSA_WITH_RC4_128_SHA (0x5) No FS 128 IE 8 / XP No FS * TLS 1.0 SSL_RSA_WITH_RC4_128_SHA (0x5) No FS 128 IE 8-10 / Win 7 TLS 1.0 SSL_RSA_WITH_RC4_128_SHA (0x5) No FS 128 IE 11 / Win 8.1 TLS 1.2 TLS_RSA_WITH_AES_256_CBC_SHA (0x35) No FS 256 Java 6u45 TLS 1.0 SSL_RSA_WITH_RC4_128_SHA (0x5) No FS 128 Java 7u25 TLS 1.0 SSL_RSA_WITH_RC4_128_SHA (0x5) No FS 128 OpenSSL 0.9.8y TLS 1.0 SSL_RSA_WITH_RC4_128_SHA (0x5) No FS 128 OpenSSL 1.0.1e TLS 1.2 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x9f) FS 256 Opera 12.15 / Win 7 TLS 1.0 SSL_RSA_WITH_RC4_128_SHA (0x5) No FS 128 Opera 15 / Win 7TLS 1.1 SSL_RSA_WITH_RC4_128_SHA (0x5) No FS 128 Safari 5.1.9 / OS X 10.6.8 TLS 1.0 SSL_RSA_WITH_RC4_128_SHA (0x5) No FS 128 Safari 6 / iOS 6.0.1TLS 1.2 TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x6b) FS 256 Safari 6.0.4 / OS X 10.8.4 TLS 1.0 SSL_RSA_WITH_RC4_128_SHA (0x5) No FS 128 Safari 7 / OS X 10.9TLS 1.2 TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x6b) FS signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora/Redhat and perfect forward secrecy
On Mon, Aug 26, 2013 at 11:17:52AM +0200, Reindl Harald wrote: cause and effect because Fedora does *not* support Ciphers without large performance impacts in reality without ECDHE you have no way go to https://www.ssllabs.com/ssltest/ and look at the client-handshakes practically no client is using PFS without ECDHE that's the truth if it comes to PFS and Redhat/Fedora http://www.internetstaff.com/roller/blog/entry/enable_elliptical_curve_diffie_hellman Not Found The requested URL /roller/blog/entry/enable_elliptical_curve_diffie_hellman was not found on this server. http://www.theverge.com/2013/6/26/4468050/facebook-follows-google-with-tough-encryption-standard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora/Redhat and perfect forward secrecy
Am 26.08.2013 16:24, schrieb Chuck Anderson: On Mon, Aug 26, 2013 at 11:17:52AM +0200, Reindl Harald wrote: cause and effect because Fedora does *not* support Ciphers without large performance impacts in reality without ECDHE you have no way go to https://www.ssllabs.com/ssltest/ and look at the client-handshakes practically no client is using PFS without ECDHE that's the truth if it comes to PFS and Redhat/Fedora http://www.internetstaff.com/roller/blog/entry/enable_elliptical_curve_diffie_hellman Not Found The requested URL /roller/blog/entry/enable_elliptical_curve_diffie_hellman was not found on this server. http://www.theverge.com/2013/6/26/4468050/facebook-follows-google-with-tough-encryption-standard and how can i quote from the URL? http://www.internetstaff.com/roller/blog/entry/enable_elliptical_curve_diffie_hellman « OpenSwan VPN between... | Main 20130721 Sunday July 21, 2013 Enable Elliptical Curve Diffie-Hellman (ECDHE) in Fedora or Amazon Linux With all the recent publicity regarding Internet spying, there has been a renewed interest in security and encryption. One oft-neglected feature of SSL is the ability to use a cipher with Diffie-Hellman key exchange that enables so-called perfect forward secrecy. The advantage of PFS is that even if your private key is compromised, recorded past traffic cannot be decrypted. The problem is that Diffie-Hellman algorithms are very slow. This can be offset to a large degree by using Elliptical Curve Diffie-Hellman (ECDHE). The problem for Red Hat / CentOS / Fedora users is that Red Hat intentionally disables ECDHE ciphers (among others) because they're unsure of the patent issues surrounding them. Fixing this requires a custom compilation of OpenSSL. Luckily, it is readily accomplished using the Fedora source RPM and does not require rolling your own binaries from scratch. In addition, you must recompile applications such as Apache's mod_ssl after installing the new OpenSSL packages. Here's how we enable ECDHE ciphers in Apache on a Fedora or Amazon Linux server: Download and install the openssl and httpd source RPMs. Download the official openssl-1.0.1e.tar.gz source package into /root/rpmbuild/SOURCES. Apply the patch below to /root/rpmbuild/SPECS/openssl.spec rpmbuild -bb openssl.spec Install the openssl-libs, and openssl-devel RPMs in /root/rpmbuild/RPMS/arch rpmbuild -bb httpd.spec Install the mod_ssl RPM in /root/rpmbuild/RPMS/arch Edit your Apache config to prefer ECDHE ciphers Restart Apache Test your Apache installation with Qualys' SSL Labs to verify your settings signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora/Redhat and perfect forward secrecy
On Mon, Aug 26, 2013 at 04:57:15PM +0200, Reindl Harald wrote: Am 26.08.2013 16:24, schrieb Chuck Anderson: On Mon, Aug 26, 2013 at 11:17:52AM +0200, Reindl Harald wrote: cause and effect because Fedora does *not* support Ciphers without large performance impacts in reality without ECDHE you have no way go to https://www.ssllabs.com/ssltest/ and look at the client-handshakes practically no client is using PFS without ECDHE that's the truth if it comes to PFS and Redhat/Fedora http://www.internetstaff.com/roller/blog/entry/enable_elliptical_curve_diffie_hellman Not Found The requested URL /roller/blog/entry/enable_elliptical_curve_diffie_hellman was not found on this server. http://www.theverge.com/2013/6/26/4468050/facebook-follows-google-with-tough-encryption-standard and how can i quote from the URL? http://www.internetstaff.com/roller/blog/entry/enable_elliptical_curve_diffie_hellman You do not use IPv6. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora/Redhat and perfect forward secrecy
On Mon, Aug 26, 2013 at 04:57:15PM +0200, Reindl Harald wrote: Not Found The requested URL /roller/blog/entry/enable_elliptical_curve_diffie_hellman was not found on this server. http://www.theverge.com/2013/6/26/4468050/facebook-follows-google-with-tough-encryption-standard and how can i quote from the URL? http://www.internetstaff.com/roller/blog/entry/enable_elliptical_curve_diffie_hellman Probably by using the old internett. The new one is broken for that URL :-) $ curl -6 --head http://www.internetstaff.com/roller/blog/entry/enable_elliptical_curve_diffie_hellman HTTP/1.1 404 Not Found Date: Mon, 26 Aug 2013 16:41:45 GMT Server: Apache Content-Type: text/html; charset=iso-8859-1 $ curl -4 --head http://www.internetstaff.com/roller/blog/entry/enable_elliptical_curve_diffie_hellman HTTP/1.1 200 OK Date: Mon, 26 Aug 2013 16:41:49 GMT Server: Apache Last-Modified: Sun, 21 Jul 2013 17:30:14 GMT Expires: Thu, 01 Jan 1970 00:00:00 GMT Content-Length: 18886 Content-Type: text/html;charset=utf-8 -jf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
