On Monday 06 February 2017 20:18:48 Andreas Bartelt wrote:
> Yes, right - thanks. I wasn't aware that this is actually a MUST
> requirement from RFC 4492. I'm quite surprised that the "Supported
> Elliptic Curves Extension" is also used in order to specify any allowed
> curves for use in the
On 02/06/17 14:44, Joel Sing wrote:
On Sunday 05 February 2017 17:05:40 Andreas Bartelt wrote:
- What type of public certificate are you using (RSA or ECDSA)?
ECDSA with P-256. Certificate signed by letsencrypt (via RSA).
Must-staple is enabled - that's why I'm also using the ocsp line for
On Sunday 05 February 2017 17:05:40 Andreas Bartelt wrote:
> > - What type of public certificate are you using (RSA or ECDSA)?
>
> ECDSA with P-256. Certificate signed by letsencrypt (via RSA).
> Must-staple is enabled - that's why I'm also using the ocsp line for
> testing.
Ah, this was the
On 02/05/17 15:41, Joel Sing wrote:
On Sunday 05 February 2017 11:13:16 Andreas Bartelt wrote:
On 02/05/17 07:41, Joel Sing wrote:
You can just specify X25519 as a group - it will not appear in `openssl
ecparam -list_curves' since it is not a standard EC curve.
thanks - I didn't notice that
On Sunday 05 February 2017 11:13:16 Andreas Bartelt wrote:
> On 02/05/17 07:41, Joel Sing wrote:
> > You can just specify X25519 as a group - it will not appear in `openssl
> > ecparam -list_curves' since it is not a standard EC curve.
>
> thanks - I didn't notice that capitalization is important
On 02/05/17 11:13, Andreas Bartelt wrote:
...
The following combinations were tested:
server httpd with ecdhe "secp384r1" & server nginx with ssl_ecdh_curve
secp384r1; (identical results)
connect via openssl [secp384r1]: fails
connect via eopenssl [secp384r1]: fails
replying to
On 02/05/17 07:41, Joel Sing wrote:
On Saturday 04 February 2017 15:51:02 Andreas Bartelt wrote:
On 02/04/17 05:26, Joel Sing wrote:
On Wednesday 01 February 2017 15:41:29 Andreas Bartelt wrote:
Hello,
after reading the LibreSSL accouncement from today, I assumed that
specifying ecdhe "auto"
On Saturday 04 February 2017 15:51:02 Andreas Bartelt wrote:
> On 02/04/17 05:26, Joel Sing wrote:
> > On Wednesday 01 February 2017 15:41:29 Andreas Bartelt wrote:
> >> Hello,
> >>
> >> after reading the LibreSSL accouncement from today, I assumed that
> >> specifying ecdhe "auto" in
On 02/04/17 17:15, Bob Beck wrote:
try connecting with openbsd nc rather than s-client
with ecdhe "auto" as well as ecdhe "secp384r1" in /etc/httpd.conf, I can
successfully negotiate a TLS cipher suite via nc -vvv -c 443
However, nc doesn't give any output with regard to the negotiated
try connecting with openbsd nc rather than s-client
On Sat, Feb 4, 2017 at 09:13 Bob Beck wrote:
>
> On Sat, Feb 4, 2017 at 07:51 Andreas Bartelt wrote:
>
> On 02/04/17 05:26, Joel Sing wrote:
> > On Wednesday 01 February 2017 15:41:29 Andreas Bartelt wrote:
>
On 02/04/17 05:26, Joel Sing wrote:
On Wednesday 01 February 2017 15:41:29 Andreas Bartelt wrote:
Hello,
after reading the LibreSSL accouncement from today, I assumed that
specifying ecdhe "auto" in /etc/httpd.conf would enable X25519, P-256
and P-384 on current.
This is correct.
I've
On Wednesday 01 February 2017 15:41:29 Andreas Bartelt wrote:
> Hello,
>
> after reading the LibreSSL accouncement from today, I assumed that
> specifying ecdhe "auto" in /etc/httpd.conf would enable X25519, P-256
> and P-384 on current.
This is correct.
> I've noticed that "auto" enables only
Hello,
after reading the LibreSSL accouncement from today, I assumed that
specifying ecdhe "auto" in /etc/httpd.conf would enable X25519, P-256
and P-384 on current.
I've noticed that "auto" enables only curves x25519 and P-256 (which is
what I'd want to use - but somehow unexpected with
13 matches
Mail list logo