> On Nov 28, 2018, at 6:31 PM, Claus Assmann wrote:
>
> Thanks for the reply, it helped me adding some more debugging
> statements to various places to track down the problem:
> it is due to a change in TLS session handling in TLSv1.3.
Thanks for following up, much appreciated.
> It seems there
Thanks for the reply, it helped me adding some more debugging
statements to various places to track down the problem:
it is due to a change in TLS session handling in TLSv1.3.
It seems there are multiple SSL_SESSION structures for a single SSL
connection (SMTP session). The callback installed usin
This was discussed around when OpenSSL first talked about the project. You
might find it worth reading the various blog entries (and comment/responses)
https://www.openssl.org/blog/blog/categories/license/ One thing to note is that
cryptography can be a patent minefield, and the patent protecti
On 28/11/18 21:41, Daniel Kahn Gillmor wrote:
> On Wed 2018-11-28 19:54:34 +, Jonathan Larmour wrote:
>> On 28/11/18 17:02, Matt Caswell wrote:
>>> Please see the following blog post about OpenSSL Versioning and License:
>>>
>>> https://www.openssl.org/blog/blog/2018/11/28/version/
>>
>> :-(
>>
On Wed 2018-11-28 19:54:34 +, Jonathan Larmour wrote:
> On 28/11/18 17:02, Matt Caswell wrote:
>> Please see the following blog post about OpenSSL Versioning and License:
>>
>> https://www.openssl.org/blog/blog/2018/11/28/version/
>
> :-(
>
> The Apache license is incompatible with GPLv2:
>
>
> On Nov 28, 2018, at 3:48 PM, Jeremy Harris wrote:
>
> Using SSL_CTX_set_tlsext_servername_callback()
> when the called routine returns SSL_TLSEXT_ERR_NOACK
> I was expecting the handshake to fail. It carries
> on; am I doing something wrong?
For an SMTP server, SNI values that don't match are
Sent from my Samsung Galaxy smartphone.--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
On 28/11/2018 21:03, Benjamin Kaduk via openssl-users wrote:
> On Wed, Nov 28, 2018 at 08:48:10PM +, Jeremy Harris wrote:
>> OpenSSL 1.1.1 FIPS 11 Sep 2018
>> RHEL 8.0 beta
>>
>> Using SSL_CTX_set_tlsext_servername_callback()
>> when the called routine returns SSL_TLSEXT_ERR_NOACK
>> I was exp
On Wed, Nov 28, 2018 at 08:48:10PM +, Jeremy Harris wrote:
> OpenSSL 1.1.1 FIPS 11 Sep 2018
> RHEL 8.0 beta
>
> Using SSL_CTX_set_tlsext_servername_callback()
> when the called routine returns SSL_TLSEXT_ERR_NOACK
> I was expecting the handshake to fail. It carries
> on; am I doing something
OpenSSL 1.1.1 FIPS 11 Sep 2018
RHEL 8.0 beta
Using SSL_CTX_set_tlsext_servername_callback()
when the called routine returns SSL_TLSEXT_ERR_NOACK
I was expecting the handshake to fail. It carries
on; am I doing something wrong?
--
Thanks,
Jeremy
--
openssl-users mailing list
To unsubscribe: h
On 28/11/18 17:02, Matt Caswell wrote:
> Please see the following blog post about OpenSSL Versioning and License:
>
> https://www.openssl.org/blog/blog/2018/11/28/version/
:-(
The Apache license is incompatible with GPLv2:
https://www.apache.org/licenses/GPL-compatibility.html
Those of us usin
Please see the following blog post about OpenSSL Versioning and License:
https://www.openssl.org/blog/blog/2018/11/28/version/
Matt
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
If GSCheck is just a tool to check if you remembered to build
code with the buffer overflow checks that Microsoft C can
insert, then you should just treat this as a warning that the
tool doesn't know how to check code from other compilers (in
this case the manual work of the OpenSSL team).
On 28/
> The 32bit OpenSSL 1.1.0i library 'libeay32.dll' fails for
> binscope GSCheck on Windows.
This must be a customised non-standard library, since 1.1.0 does not
build with that name, but as libcrypto-1_1.dll.
Angus
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/l
I thibk those are all the .asm modules. If they are, you'll probably want
to Configure with no-asm and rebuild in order to get the C implementations.
-Kyle H
On Wed, Nov 28, 2018, 01:07 Vinay Kumar via openssl-users <
openssl-users@openssl.org wrote:
> Hi All,
>
> The 32bit OpenSSL 1.1.0i libra
Hi all,
I'm currently implementing a TPM2 engine for OpenSSL over at
https://github.com/tpm2-software/tpm2-tss-engine
The problem I'm facing is that OpenSSL's TLS negotiation will request ECDSA
from my engine with any hash alg, even though the TPM's keys are restricted to
just one specific hash
Hi All,
The 32bit OpenSSL 1.1.0i library 'libeay32.dll' fails for binscope GSCheck on
Windows.
E:\libeay32.dll: error BA2022: libeay32.dll was compiled with the following
modules for which a language could not be identified. Ensure these were
compiled with debug information and run BinScope ag
17 matches
Mail list logo
