early openssl and curl forks that support ESNI
Hiya, We've done some work on an openssl fork [1] that has ESNI support and on a curl fork [2] that uses that. It's early days, but if anyone wants to try play with the build and give us feedback that'd be great. There's a HOWTO at [3]. If you find any issues with that you'd like to raise then please raise an issue at [1] or [2], or send mail. Thanks, Stephen. [1] https://github.com/sftcd/openssl/tree/master/esnistuff [2] https://github.com/niallor/curl [3] https://defo.ie/building-curl-openssl-with-esni.html 0x5AB2FAF17B172BEA.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
OPENSSL_armcap_P, OPENSSL_ia32_P, OPENSSL_ppccap_P
Hi, I'm using openssl on a platform/OS that supports multiple CPU architectures. The context switching does not save SIMD registers unless the thread has a special options set. This creates some challenges when using openssl, which use SIMD registers in several assembler optimizations. I would like to ensure that no assembler optimization can be used if the special option is not set. If the appropriate bits in OPENSSL_armcap_P/OPENSSL_ia32_P/OPENSSL_ppccap_P is disabled, will that guarantee that no instructions using SIMD registers are executed? There is some OPENSSL_XXXcap_P code within #ifndef __KERNEL__ which indicates that openssl is used in the linux kernel. I believe the linux kernel would have a similar situation regarding SIMD registers. Floating point operations and operations SIMD registers cannot be used in the linux kernel. But I am unable to find any information that confirms that this would cover all code paths. Regards Roger
OPENSSL_armcap_P, OPENSSL_ia32_P, OPENSSL_ppccap_P
Hi, I'm using openssl on a platform/OS that supports multiple CPU architectures. The context switching does not save SIMD registers unless the thread has a special options set. This creates some challenges when using openssl, which use SIMD registers in several assembler optimizations. I would like to ensure that no assembler optimization can be used if the special option is not set. If the appropriate bits in OPENSSL_armcap_P/OPENSSL_ia32_P/OPENSSL_ppccap_P is disabled, will that guarantee that no instructions using SIMD registers are executed? There is some OPENSSL_XXXcap_P code within #ifndef __KERNEL__ which indicates that openssl is used in the linux kernel. I believe the linux kernel would have a similar situation regarding SIMD registers. Floating point operations and operations SIMD registers cannot be used in the linux kernel. But I am unable to find any information that confirms that this would cover all code paths. Regards Roger
Re: [TLS] TLSv1.2 - Is zero signature allowed in client CertificateVerify message?
> On Sep 3, 2019, at 11:27 AM, M K Saravanan wrote: > > Thanks Richard for the reply. Let me rephrase my question: > > If a client encounter any error condition (e.g. does not have access to the > private key for whatever reason) in generating the signature, can it send > zero bytes in the signature field of CertificateVerify message to indicate > the error condition? Is this allowed in TLS 1.2 RFC? There is nothing special about an all zero or any other sequence of characters in the signature. A signature is either valid or not. A client that does not possess the private key for its certificate can decline the server's request for a client certificate, by sending a zero-length ClientCertificate and no ClientVerify. -- Viktor.
OPENSSL_armcap_P, OPENSSL_ia32_P, OPENSSL_ppccap_P
Hi, I'm using openssl on a platform/OS that supports multiple CPU architectures. The context switching does not save SIMD registers unless the thread has a special options set. This creates some challenges when using openssl, which use SIMD registers in several assembler optimizations. I would like to ensure that no assembler optimization can be used if the special option is not set. If the appropriate bits in OPENSSL_armcap_P/OPENSSL_ia32_P/OPENSSL_ppccap_P is disabled, will that guarantee that no instructions using SIMD registers are executed? There is some code within #ifndef __KERNEL__ which indicates that openssl is used in the linux kernel. I believe the linux kernel would have a similar situation regarding SIMD registers. Floating point operations and operations SIMD registers cannot be used in the linux kernel. But I am unable to find any information that confirms that this would cover all code paths. Regards Roger
Forthcoming OpenSSL Releases
The OpenSSL project team would like to announce the forthcoming release of OpenSSL versions 1.1.1d, 1.1.0l and 1.0.2t. These releases will be made available on 10th September 2019 between approximately 1200-1600 UTC. These are security fix releases. The highest severity security issue fixed by these releases is rated as LOW. Please note that this is expected to be the last release of 1.1.0 before it goes out of support on 11th September 2019. Yours The OpenSSL Project Team signature.asc Description: OpenPGP digital signature
RE: Compiling OpenSSL 1.1 - certs directory is empty, how to obtain?
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of > Pete Cooper > Sent: Saturday, August 24, 2019 13:10 > The `config` and subsequent `make` complete without any visible issues shown. > However, > /etc/php/shared/openssl/certs is an empty directory. > Are there OpenSSL compile flags to explicitly build or obtain the current > up-to-date > *.pem files for my PHP-only OpenSSL build, or should be looking elsewhere? I haven't seen a response to this on the list. OpenSSL does not include a collection of trusted certificates. You need to get them from some other source. You may copy them from your OS distribution, for example. Another popular source is the Mozilla certificate collection. Adam Langley wrote a Go program that converts the Mozilla collection to PEM and excludes those marked as untrusted; you can find it at: https://github.com/agl/extract-nss-root-certs (And Go itself is available from https://golang.org, of course, if you don't have that installed.) There are many opinions about what constitutes a good collection of trust anchors for various applications. Some people feel the collections provided with most OS and browser distributions are too generous, and saccrifice security for interoperability. If you're going to assemble a set of trust anchors that includes public CAs, it may be a good idea to familiarize yourself with the issues. Ivan Ristic's /Bulletproof SSL and TLS/ (available at https://feistyduck.com) has a good survey. -- Michael Wojcik Distinguished Engineer, Micro Focus
