On Fri, May 1, 2020 at 6:36 AM Richard Levitte wrote:
>
> On Sun, 26 Apr 2020 11:35:14 +0200,
> Yann Ylavic wrote:
> >
> > On Sun, Apr 26, 2020 at 12:15 AM Kurt Roeckx wrote:
> > >
> > > On Fri, Apr 24, 2020 at 01:26:05PM +0200, Yann Ylavic wrote:
> >
On Sun, Apr 26, 2020 at 12:15 AM Kurt Roeckx wrote:
>
> On Fri, Apr 24, 2020 at 01:26:05PM +0200, Yann Ylavic wrote:
> >
> > - DH_bits(dh) (used for logging only in httpd)
> > Replaced by BN_num_bits(DH_get0_p(dh)).
> > Not sure this one should be deprecated,
On Fri, Apr 24, 2020 at 5:50 PM The Doctor wrote:
>
> I will also test on httpd , php 74 et al.
This commit might help if you want to test httpd trunk/master:
https://github.com/apache/httpd/commit/316aea784d9423688ea38943d95d1d2b614fc921
Regards,
Yann.
On Fri, Apr 24, 2020 at 1:26 PM Yann Ylavic wrote:
>
> - Custom input BIO_METHOD (using httpd filters' stack) asserted its
> _ctrl() was never called, so far..
> The new BIO_eof() calls in codebase, notably from ssl3_read_n(),
> breaks this assertion.
> Handling the case f
Hi team,
I gave 3.0.0-alpha1 a try with Apache httpd.
tl;dr it works with minimal changes, congrats!
The changes needed on httpd side:
- SSL_CTX_load_verify_locations() and X509_STORE_load_locations()
Replaced by {SSL_CTX,X590_STORE}_load_verify_file() +
{SSL_CTX,X590_STORE}_load_verify_{dir,pat
On Thu, Apr 23, 2020 at 5:12 PM Dr. Matthias St. Pierre
wrote:
>
> > For each new release, it seems that the tarball is published in the
> > "/source" directory (website) while the previous one is moved to
> > "/source/old/".
> >
> > Would it be possible that all releases land in "/source/old",
>
Hi team,
For each new release, it seems that the tarball is published in the
"/source" directory (website) while the previous one is moved to
"/source/old/".
Would it be possible that all releases land in "/source/old",
including the new one when published? After all anything is more or
less old,
, 2019 at 02:30:37PM +0200, Yann Ylavic wrote:
> >
> > And it _seems_ that browsers (or Chrome only?) don't set a
> > tlsext_hostname in their session (ASN1) on resumption, so
>
> I don't understand what you mean by "set a tlsext_hostname in their session
>
Hi,
in master (and 1.1.1), SSL_get_servername() returns either
s->session->ext.hostname (when s->hit == 1), or s->ext.hostname
(otherwise).
It seems, according to final_server_name(), that
s->session->ext.hostname is set only:
if (sent && ret == SSL_TLSEXT_ERR_OK && (!s->hit || SSL_IS_TLS
On Tue, Mar 5, 2019 at 2:16 PM Yann Ylavic wrote:
>
> Also the double dlopen() could be opt-in/out at init time (some new
> OPENSSL_INIT_[NO_]UNLOAD option), which looks far better for
> usability, and with the right compatibility default could possibly
> make it to 1.1 :p
FWIW, I
On Tue, Mar 5, 2019 at 6:05 PM Tomas Mraz wrote:
>
> On Tue, 2019-03-05 at 16:00 +0100, Yann Ylavic wrote:
> > On Tue, Mar 5, 2019 at 2:47 PM Tomas Mraz wrote:
> > >
> > Why? Distros know better than the applications they run?
>
> They actually do, because appl
On Tue, Mar 5, 2019 at 2:47 PM Tomas Mraz wrote:
>
> But is it in reality at all possible to explicitly unload OpenSSL?
Well, I don't want to forcibly unload openssl precisely, I want it to
unload when its refcount reaches zero.
> You're talking here about mod_ssl but what if the OpenSSL is load
On Tue, Mar 5, 2019 at 12:51 PM Matt Caswell wrote:
>
> On 04/03/2019 23:37, Yann Ylavic wrote:
> > So my question is, why isn't no-pinshared the default?
> > ISTM that pinshared is enabled on linux only,
>
> That isn't correct. pinshared is the default everywhe
Hi,
after quite some time trying to convert Apache httpd (and libapr) to
new the OPENSSL_init/cleanup() 1.1 API, and wondering why openssl libs
would not unload with mod_ssl as before (1.0 and earlier), I found the
ELF NODELETE flag (gcc's -znodelete) and the new (no-)pinshared config
option (thou
On Mon, Jan 14, 2019 at 1:09 PM Matt Caswell wrote:
>
> This works more "by accident". There is no ciphersuite alias called "TLSv1.3",
> so using it as above results in no ciphersuites matched. Since the TLSv1.3
> ciphersuites are on by default anyway that's all that you get back.
OK, thanks for
On Tue, Jan 8, 2019 at 11:24 PM Sam Roberts wrote:
>
> node.js has an API that lists all the cipher suite names that can be
> validly passed to set_cipher_list(), but I don't see how to get them
> for TLS1.3 to list the valid inputs to set_cipher_suites().
FWIW, the below works for me:
$ openssl
On Thu, Jun 21, 2018 at 12:17 AM, Yann Ylavic wrote:
>
> Right but if s_server had handled SSL_CB_HANDSHAKE_START/DONE in its
> info callback (like s_client), you'd see "SSL negotiation finished
> successfully" after each ticket, even if the server knows (or could).
Hm
On Wed, Jun 20, 2018 at 11:49 PM, Matt Caswell wrote:
>
> On 20/06/18 22:31, Yann Ylavic wrote:
>>
>> but I wonder if
>> announcing the start then end of the same handshake multiple times
>> could/should be avoided (i.e. handshake ends after last ticket only)?
>>Thanks, it does not happen with mozzilla implementation
> (tls13.crypto.mozilla.org), is this openssl specific or part of the
> specification?
>
> The specification allows a server to send one or more tickets, at its
> discretion.
OK thanks, I could find the relevant PR and rational
On Wed, Jun 20, 2018 at 8:59 PM, Viktor Dukhovni
wrote:
>
>
>> On Jun 20, 2018, at 2:55 PM, Yann Ylavic wrote:
>>
>> Hi,
>>
>> connecting s_client to s_server with TLS 1.3 seems to cause two
>> successive session tickets to be sent by the server (s
Hi,
connecting s_client to s_server with TLS 1.3 seems to cause two
successive session tickets to be sent by the server (see below).
Is this expected?
$ openssl s_server -accept 127.0.0.1:4443 -cert ... -key ... -state
Using default temp DH parameters
ACCEPT
SSL_accept:before SSL initialization
21 matches
Mail list logo
