Hello,
I use OpenSSL version is openssl-1.1.0h(Windows) and
I run following command from apps directory
openssl s_server -accept 443 -www
The server in this case use certificate "server.pem"
On client computer I run command
openssl s_client -connect 10.65.48.108:443
On client computer I get error
On 30.05.2018 08:45, Mark Shnaider via openssl-users wrote:
Hello,
I use OpenSSL version is openssl-1.1.0h(Windows) and
I run following command from apps directory
|openssl s_server -accept 443 -www|
The server in this case use certificate "server.pem"
On client computer I run command
ope
After some RTFM, I found space_ec .. which confirms that this change was
intentional.
Thanks
On 29/05/18 16:27, tincanteksup wrote:
Hi,
Certificate included here is only for testing.
I use EasyRSA to build my PKI -- This all works well.
So, now I have a client cert but, depending on which
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
> Of FooCrypt
> Sent: Tuesday, May 29, 2018 21:41
> To: openssl-users@openssl.org
> Subject: Re: [openssl-users] PRNG is not seeded
>
> > On 30 May 2018, at 8:58 AM, Scott Neugroschl
> wrote:
> >
> > I’m using PRNGD to seed
> On 30 May 2018, at 11:55 PM, Michael Wojcik
> wrote:
>
>> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
>> Of FooCrypt
>> Sent: Tuesday, May 29, 2018 21:41
>> To: openssl-users@openssl.org
>> Subject: Re: [openssl-users] PRNG is not seeded
>>
>>> On 30 May 2018, at
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
> Of FooCrypt
> Sent: Wednesday, May 30, 2018 10:46
> To: openssl-users@openssl.org
> Subject: Re: [openssl-users] PRNG is not seeded
>
> > On 30 May 2018, at 11:55 PM, Michael Wojcik
> wrote:
> >
> > Where would openssl ra
>>> I’m using PRNGD to seed my random numbers (I’m on a system without
>>> /dev/random and /dev/urandom). I occasionally get the dreaded “PRNG is
>>> not seeded” error.
>>
>> I don’t know your OS or environment, have you tried the ‘openssl rand’
>> functionality as a random source to seed your en
> On 31 May 2018, at 1:35 AM, Michael Wojcik
> wrote:
>
>> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
>> Of FooCrypt
>> Sent: Wednesday, May 30, 2018 10:46
>> To: openssl-users@openssl.org
>> Subject: Re: [openssl-users] PRNG is not seeded
>>
>>> On 30 May 2018, a
In message
on Wed, 30 May 2018 15:37:47 +, Scott Neugroschl said:
scott_n> The platform in question is an HPE NonStop.
NonStop isn't the only platform with this sort of problem... I'd
suggest asking in places dedicated to NonStop if they know of good
enough ways to gather enough entropy,
On 05/29/2018 01:48 AM, Viktor Dukhovni wrote:
> I am rather puzzled as to why you chose to eliminate
> not just fixed DH, but also the ephemeral finite-field
> DH key exchange. What's wrong with the DHE ciphers?
Mostly precomputation attacks: https://weakdh.org/logjam.html
Those parameters are "e
> On May 30, 2018, at 12:54 PM, Michał Trojnara
> wrote:
>
>> I am rather puzzled as to why you chose to eliminate
>> not just fixed DH, but also the ephemeral finite-field
>> DH key exchange. What's wrong with the DHE ciphers?
>
> Mostly precomputation attacks: https://weakdh.org/logjam.htm
> Either way, trying to use OpenSSL's PRNGD to seed OpenSSL's PRNGD is an
> exercise in futility.
Oh, I agree on that.
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
On 5/30/2018 1:16 AM, Walter H. wrote:
> On 30.05.2018 08:45, Mark Shnaider via openssl-users wrote:
>> [...]
>>
>> openssl s_client -connect 10.65.48.108:443
>>
>> [...]
> very probable, that the client doesn't have the root ca certificate of
> the ca certificate that signed server.pem
>
> you sho
> On May 30, 2018, at 4:06 PM, Jordan Brown
> wrote:
>
> And also: the certificate is unlikely to list an IP address, so it should
> fail hostname verification. You need to use a host name in your client
> connection request, not an IP address.
>
> (Pretty much, you don't ever want to us
On 30.05.2018 19:12, Viktor Dukhovni wrote:
> So I would disable only kDH, but not DHE. Keep in mind that
> some remote systems will not support EECDH, and by disabling
> DHE, you get only kRSA, which is worse. So I think that
> '!DH' is unwise.
I respectfully disagree. The only practical disad
> On May 31, 2018, at 12:09 AM, Michal Trojnara
> wrote:
>
> I respectfully disagree. The only practical disadvantage of kRSA is
> that it doesn't provide PFS. Losing PFS is bad, but it's not a huge
> price for ensuring secure key exchange.
There's an assumption here that DHE key exchange
16 matches
Mail list logo