On Thursday, May 28, 2015 2:29 PM, Lukas Tribus wrote:
If your refer to long EOL'ed system, then they probably don't support DHE
at all.
Alas EOL'ed systems doesn't hinder its use - even if it unwise..
Thats not what I'm saying. What I'm saying is that since they are so old they
Hi Lukas,
On Mon, Jun 01, 2015 at 12:36:13PM +0200, Lukas Tribus wrote:
I pushed this into 1.6. I'd rather issue -dev2 with it, wait a little bit
then backport it into 1.5 if we don't get any negative feedback. We might
have to help distro maintainers prepare some arguments to backport
Hi Willy,
Thank you, that was pretty clear and easy. I checked that I was running
with about 2 kb of entropy before the tests and that I was alone on the
machine, so I'm confident that what I did wasn't skewed.
I pushed this into 1.6. I'd rather issue -dev2 with it, wait a little bit
then
Hi Rémi,
On Fri, May 29, 2015 at 04:36:49PM +0200, Remi Gacogne wrote:
I expect to be able to send the ssl-dh-param-file patch tomorrow, as it
is mostly written (but not well tested yet), as well as the patch to
move from 1024-bit DH to 2048-bit by default.
Great! Do you think it would
Hi Willy,
On 05/28/2015 06:19 PM, Willy Tarreau wrote:
RSA 1024 is (at last) being phased out, and we have
seen on this mailing-list that a DH greater than 2048-bit is simply too
costly for a lot of users.
OK so that means that probably people will prefer to build their own
DH-1024 to use
Hi Julien,
On 05/27/2015 12:05 PM, Julien Vehent wrote:
This is by far the best write-up on DHE compatibility issues I've seen.
Would you mind organizing your research into something we could publish
on https://wiki.mozilla.org/Security/Server_Side_TLS ?
I've added some notes about
On Tuesday, May 26, 2015 5:12 PM Remi Gacogne wrote:
On 05/23/2015 08:47 AM, Willy Tarreau wrote:
Do you have any idea about the ratio of clients (on the net) which don't
support ECDHE right now but support DHE ?
Basically, by totally removing DHE, we would be losing forward secrecy for:
-
On Tuesday, May 26, 2015 5:12 PM Remi Gacogne wrote:
On 05/23/2015 08:47 AM, Willy Tarreau wrote:
Do you have any idea about the ratio of clients (on the net) which don't
support ECDHE right now but support DHE ?
Basically, by totally removing DHE, we would be losing forward secrecy for:
On Thursday, May 28, 2015 12:35 PM Lukas Tribus wrote:
What about other clients (ie. browsers running on different OS
combinations) - especially legacy systems?
If your refer to long EOL'ed system, then they probably don't support DHE at
all.
Alas EOL'ed systems doesn't hinder its use
If your refer to long EOL'ed system, then they probably don't support DHE at
all.
Alas EOL'ed systems doesn't hinder its use - even if it unwise..
Thats not what I'm saying. What I'm saying is that since they are so old they
don't
even support DHE, therefor the dh group doesn't matter.
Hi Rémi,
On Thu, May 28, 2015 at 05:45:43PM +0200, Remi Gacogne wrote:
Just a question, does it make sense to have different dh-param files
per key size so that depending on the cert key size we use a different
file, or are they totally decorrelated ?
I used to think that it made sense,
I think the new setting for a global dhparam file is a great idea.
On May 26, 2015 11:12 AM, Remi Gacogne rgaco...@aquaray.fr wrote:
Hi,
On 05/23/2015 08:47 AM, Willy Tarreau wrote:
Do you have any idea about the ratio of clients (on the net) which don't
support ECDHE right now but
Hi Rémi,
On Tue, May 26, 2015 at 05:11:36PM +0200, Remi Gacogne wrote:
Hi,
On 05/23/2015 08:47 AM, Willy Tarreau wrote:
Do you have any idea about the ratio of clients (on the net) which don't
support ECDHE right now but support DHE ?
Basically, by totally removing DHE, we would be
Hi,
On 05/23/2015 08:47 AM, Willy Tarreau wrote:
Do you have any idea about the ratio of clients (on the net) which don't
support ECDHE right now but support DHE ?
Basically, by totally removing DHE, we would be losing forward secrecy for:
- Java = 6 ;
- OpenSSL = 1.0.0 ;
- Android = 3.
Note
Generating dhparams can result in wildly different runtimes... Just running
a dhparm 1024 here resulted in times between 1.3 and 12 second... I've
generated a bunch of 2048 dhparams, which took between 1 and 30 minutes
depends on luck, finding the right set of good primes.
But generating 1024
Hi Rémi,
On Fri, May 22, 2015 at 10:53:08AM +0200, Remi Gacogne wrote:
Otherwise it makes no sense, sorry about that.
ah ?
Well, with the previous command I was basically saying if a DH 2048-bit
group is too much CPU-consuming for you, just use a 2048-bit group,
which makes no sense
Hi Rémi,
On Fri, May 22, 2015 at 09:11:39AM +0200, Remi Gacogne wrote:
Hello,
On 05/22/2015 07:32 AM, Willy Tarreau wrote:
That makes me think about something, as you advocated a long time ago
for increasing the dh-param default size. Do you think we should take
the opportunity of 1.6
Hi Remi,
On Thu, May 21, 2015 at 06:07:34PM +0200, Remi Gacogne wrote:
In the default configuration, Haproxy uses a 1024-bit DH key generated
from the second Oakley group [2] for Diffie-Hellman Ephemeral (DHE) key
exchange. This group is widely used, and is likely to be the first
target for
18 matches
Mail list logo
