On Thu, October 20, 2016 7:38 am, Leonard den Ottolander wrote:
> Hello Alice,
>
> On Wed, 2016-10-19 at 14:22 -0700, Alice Wonder wrote:
>> I formerly used secp521r1 but suddenly Google with no warning stopped
>> supporting it in chrome. That company is too powerful.
It is. As anything behind w
Hello Alice,
On Wed, 2016-10-19 at 14:22 -0700, Alice Wonder wrote:
> I formerly used secp521r1 but suddenly Google with no warning stopped
> supporting it in chrome. That company is too powerful.
Actually this is something the NSA insists on:
https://www.iad.gov/iad/customcf/openAttachment.cfm
Hi,
On Thu, 2016-10-20 at 13:47 +0200, Leonard den Ottolander wrote:
> The point Bernstein makes in the article I referenced is not so much
> that the NIST curves are suspect (for the reasons you mention) but the
> fact that the ECDSA algorithm itself is such that it is virtually
> impossible to i
Hello Alice,
On Wed, 2016-10-19 at 13:40 -0700, Alice Wonder wrote:
> On 10/19/2016 11:34 AM, Leonard den Ottolander wrote:
> > Personally I would be more concerned whether or not to enable ECDSA
> > algorithms (https://blog.cr.yp.to/20140323-ecdsa.html).
> For web server ECDSA certs is currently
On 10/19/2016 01:54 PM, m.r...@5-cent.us wrote:
Alice Wonder wrote:
On 10/19/2016 11:34 AM, Leonard den Ottolander wrote:
Hello Gordon,
*snip*
Personally I would be more concerned whether or not to enable ECDSA
algorithms (https://blog.cr.yp.to/20140323-ecdsa.html).
For web server ECDSA c
Alice Wonder wrote:
> On 10/19/2016 11:34 AM, Leonard den Ottolander wrote:
>> Hello Gordon,
>>
> *snip*
>>
>> Personally I would be more concerned whether or not to enable ECDSA
>> algorithms (https://blog.cr.yp.to/20140323-ecdsa.html).
>>
> For web server ECDSA certs is currently a concern becaus
On 10/19/2016 11:34 AM, Leonard den Ottolander wrote:
Hello Gordon,
*snip*
Personally I would be more concerned whether or not to enable ECDSA
algorithms (https://blog.cr.yp.to/20140323-ecdsa.html).
Regards,
Leonard.
For web server ECDSA certs is currently a concern because the only
curv
On Thu, Oct 20, 2016 at 4:30 AM, Leonard den Ottolander <
leon...@den.ottolander.nl> wrote:
> Hello Clint,
>
> On Wed, 2016-10-19 at 11:28 +1300, Clint Dilks wrote:
> > The following weak client-to-server encryption algorithms are supported
> by
> > the remote service:
> > rijndael-...@lysator.liu
Hello Gordon,
On Wed, 2016-10-19 at 10:31 -0700, Gordon Messmer wrote:
> On 10/19/2016 08:30 AM, Leonard den Ottolander wrote:
> > Where did you get the idea that AES (~ Rijndael) is a weak cipher?
>
>
> It's not the cipher, but the mode. CBC has several known weaknesses in
> TLS, and is frequ
On 10/19/2016 08:30 AM, Leonard den Ottolander wrote:
Where did you get the idea that AES (~ Rijndael) is a weak cipher?
It's not the cipher, but the mode. CBC has several known weaknesses in
TLS, and is frequently regarded as potentially insecure as a result.
https://www.openssl.org/~bodo
Am 19.10.2016 um 17:30 schrieb Leonard den Ottolander
:
> Hello Clint,
>
> On Wed, 2016-10-19 at 11:28 +1300, Clint Dilks wrote:
>> The following weak client-to-server encryption algorithms are supported by
>> the remote service:
>> rijndael-...@lysator.liu.se
>> arcfour256
>> arcfour128
>> aes25
Am 19.10.2016 um 17:05 schrieb Chris Adams :
> Once upon a time, Erik Laxdal said:
>> The supported KexAlgorithms, Ciphers, and MACs are generally listed
>> in the sshd_config man page. So 'man sshd_config' then look for the
>> section of the item of interest.
>
> Note that the man page does not
Hello Clint,
On Wed, 2016-10-19 at 11:28 +1300, Clint Dilks wrote:
> The following weak client-to-server encryption algorithms are supported by
> the remote service:
> rijndael-...@lysator.liu.se
> arcfour256
> arcfour128
> aes256-cbc
> 3des-cbc
> aes192-cbc
> blowfish-cbc
> cast128-cbc
> arcfour
Once upon a time, Erik Laxdal said:
> The supported KexAlgorithms, Ciphers, and MACs are generally listed
> in the sshd_config man page. So 'man sshd_config' then look for the
> section of the item of interest.
Note that the man page does not always match the actual compiled binary
(the build pr
On 2016-10-19 03:11, Leon Fauster wrote:
Is there any command to find the supported list of KeyAlgos, MACs and
Ciphers for
the particular system (e.g. EL{5,6,7})? Similar to $ openssl ciphers
-v ...
The supported KexAlgorithms, Ciphers, and MACs are generally listed in
the sshd_config man pa
Am 19.10.2016 um 00:58 schrieb Gordon Messmer :
> On 10/18/2016 03:28 PM, Clint Dilks wrote:
>> So first
>> question is are people generally modifying the list of ciphers supported by
>> the ssh client and sshd?
>
> I suspect that "generally" people are not. I do, because I can, and so that
> I
On 10/18/2016 03:28 PM, Clint Dilks wrote:
So first
question is are people generally modifying the list of ciphers supported by
the ssh client and sshd?
I suspect that "generally" people are not. I do, because I can, and so
that I can offer at least some advice to people who aim to do so.
On CentOS 7 I put the following at the end of ssh
KexAlgorithms
curve25519-sha...@libssh.org,diffie-hellman-group-exchange-sha256
I believe that prevents the CBC ciphers from being used.
CentOS 6 I *think* does not support curve25519 so that one may not be an
option for CentOS 6. That really
Hi,
In a recent security review some systems I manage were flagged due to
supporting "weak" ciphers, specifically the ones listed below. So first
question is are people generally modifying the list of ciphers supported by
the ssh client and sshd?
On CentOS 6 currently it looks like if I remove a
19 matches
Mail list logo
