Re: Quantum-Resistant Cryptographic Algorithms
The project will once they are formally standardised. In the meantime, the Open Quantum Safe project has a provider that implements all of the candidate algorithms (https://github.com/open-quantum-safe/oqs-provider). Pauli On 1/11/22 15:14, ad...@redtile.com wrote: Will OpenSSL persue/support the four new NIST Quantum Cryptographic Algorithms? https://www.nist.gov/news-events/news/2022/07/nist-announces-first-four-quantum-resistant-cryptographic-algorithms
自动回复: Re: issues with OpenSSL 1.1.1n
这是一封自动回复邮件。已经收到您的来信，我会尽快回复。
Re: issues with OpenSSL 1.1.1n
On Tue, Nov 01, 2022 at 06:08:10PM -0500, Ray Crumrine wrote: > Oh my gosh! Thank you. I am a newbie when it comes to certificates. I > am only using tls for outbound calls. I thought I shouldn't need a > certificate when doing outbound only [a client] but was getting some > weird error. After I read your email I simply commented out both > "certificate" lines in my configuration and it works!!! You don't need (and generally should not configure) client certificates for connections to random servers that are not specifically expected to authenticate your client certificates. > One last question. I don't need certbot at all then, right? If you're not running any TLS-enabled servers, and no server expects hostname-based TLS client certificates from your client, then indeed you do not need certbot. It vends TLS server/client certificates for domain names based on trust-on-first-use verified DNS domain control. -- Viktor.
issues with OpenSSL 1.1.1n
Oh my gosh! Thank you. I am a newbie when it comes to certificates. I am only using tls for outbound calls. I thought I shouldn't need a certificate when doing outbound only [a client] but was getting some weird error. After I read your email I simply commented out both "certificate" lines in my configuration and it works!!! One last question. I don't need certbot at all then, right? Thanks again, Ray Viktor Dukhovni wrote: > On Tue, Nov 01, 2022 at 05:55:08AM -0500, Ray Crumrine wrote: > >> SSL SSL_ERROR_SSL (Handshake): Level: 0 err: <336151573> > routines-ssl3_read_bytes-sslv3 alert certificate expired> > Is this logged by the TLS client or server? In other words are you > running a client application making outgoing connections or a server > application receiving incoming connections? > >> but not all of the time. Only when I try to access >> us-east-va.sip.flowroute using tlsv1.2. > This sounds like "client". TLS alerts are sent by the other end of the > connection, so if you're getting "certificate expired" alerts from a > server, that means that your client is *sending* an expired certificate > to the server (which must have solicited, possibly optional, client > certificates). The server in question does send certificate requests: > > Transport Layer Security > TLSv1.2 Record Layer: Handshake Protocol: Certificate Request (fragment) > Content Type: Handshake (22) > Version: TLS 1.2 (0x0303) > Length: 16384 > Handshake Protocol: Certificate Request (fragment) > ... > >> I have tried two other sites using the same configuration and they work >> fine. Is there a simple configuration change or do I need Openssl v3.0? > The other sites presumably don't solicit client certificates. The > simplest choice is to not configure a client certificate unless you're > sure you're going to need one. > >> Checking with >> https://decoder.link/sslchecker/us-east-va.sip.flowroute.com/5061 >> everything checks fine??? > The probe does not send expired client certs. >
an oldie but a goodie .. ISO C90 does not support 'long long'
Good day : This always bites me when I try strict C90 : In file included from include/openssl/x509.h:41, from apps/include/apps.h:29, from apps/lib/app_libctx.c:10: include/openssl/sha.h:106:37: error: ISO C90 does not support 'long long' [-Wlong-long] 106 | # define SHA_LONG64 unsigned long long | ^~~~ include/openssl/sha.h:110:5: note: in expansion of macro 'SHA_LONG64' 110 | SHA_LONG64 h[8]; | ^~ include/openssl/sha.h:106:37: error: ISO C90 does not support 'long long' [-Wlong-long] 106 | # define SHA_LONG64 unsigned long long | ^~~~ include/openssl/sha.h:111:5: note: in expansion of macro 'SHA_LONG64' 111 | SHA_LONG64 Nl, Nh; | ^~ include/openssl/sha.h:106:37: error: ISO C90 does not support 'long long' [-Wlong-long] 106 | # define SHA_LONG64 unsigned long long | ^~~~ include/openssl/sha.h:113:9: note: in expansion of macro 'SHA_LONG64' 113 | SHA_LONG64 d[SHA_LBLOCK]; | ^~ gmake[1]: *** [Makefile:3989: apps/lib/libapps-lib-app_libctx.o] Error 1 gmake[1]: Leaving directory '/opt/bw/build/openssl-3.0.7_debian_ppc64.002' make: *** [Makefile:2958: build_sw] Error 2 etc etc ... I can just as neatly go to C11 or some such but I thought the whole code base was C90 clean ? At least it was. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional
stunnel 5.67 released
Dear Users, I have released version 5.67 of stunnel. ### Version 5.67, 2022.11.01, urgency: HIGH * Security bugfixes - OpenSSL DLLs updated to version 3.0.7. * New features - Provided a logging callback to custom engines. * Bugfixes - Fixed "make cert" with OpenSSL older than 3.0. - Fixed the code and the documentation to use conscious language for SNI servers (thx to Clemens Lang). Home page: https://www.stunnel.org/ Download: https://www.stunnel.org/downloads.html SHA-256 hashes: 3086939ee6407516c59b0ba3fbf555338f9d52f459bcab6337c0f00e91ea8456 stunnel-5.67.tar.gz a6bdc2a735eb34465d10e3c7e61f32d679ba29a68de8ea8034db79c0c8b328a3 stunnel-5.67-win64-installer.exe 893f53d6647900eb34041be8f21a21c052a31de3fb393a97627021a1ef2752f5 stunnel-5.67-android.zip Best regards, Mike OpenPGP_signature Description: OpenPGP digital signature
Re: PGP key
Hi Mike, the signing key is a sub key of the key listed on this web site: https://www.openssl.org/community/otc.html The primary key fingerprint is also mentioned at https://github.com/openssl/openssl/blob/master/doc/fingerprints.txt Regards, Tomas Mraz, OpenSSL On Tue, 2022-11-01 at 18:14 +, Mike Banahan wrote: > Hi Tomas - I received information today abut the buffer overflow fix, > signed with what I believe is your PGP key. > > There is no mention of your key on the OpenSSL website, I eventually > found it on a keyserver. > > I realize that this is not the most important thing in the world, but > I > think it would help the verification process if the public key was > easily visible on the website! > > Many thanks for all your work, which is most appreciated. > > Best wishes, > > Mike Banahan > -- Tomáš Mráz, OpenSSL
New Blog Post: CVE-2022-3786 and CVE-2022-3602: X.509 Email Address Buffer Overflows
Please see the new blog post here: https://www.openssl.org/blog/blog/2022/11/01/email-address-overflows/ OpenPGP_0xD9C4D26D0E604491.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
OpenSSL Security Advisory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenSSL Security Advisory [01 November 2022] X.509 Email Address 4-byte Buffer Overflow (CVE-2022-3602) == Severity: High A buffer overrun can be triggered in X.509 certificate verification, specifically in name constraint checking. Note that this occurs after certificate chain signature verification and requires either a CA to have signed the malicious certificate or for the application to continue certificate verification despite failure to construct a path to a trusted issuer. An attacker can craft a malicious email address to overflow four attacker-controlled bytes on the stack. This buffer overflow could result in a crash (causing a denial of service) or potentially remote code execution. Many platforms implement stack overflow protections which would mitigate against the risk of remote code execution. The risk may be further mitigated based on stack layout for any given platform/compiler. Pre-announcements of CVE-2022-3602 described this issue as CRITICAL. Further analysis based on some of the mitigating factors described above have led this to be downgraded to HIGH. Users are still encouraged to upgrade to a new version as soon as possible. In a TLS client, this can be triggered by connecting to a malicious server. In a TLS server, this can be triggered if the server requests client authentication and a malicious client connects. OpenSSL versions 3.0.0 to 3.0.6 are vulnerable to this issue. OpenSSL 3.0 users should upgrade to OpenSSL 3.0.7. OpenSSL 1.1.1 and 1.0.2 are not affected by this issue. This issue was reported to OpenSSL on 17th October 2022 by Polar Bear. The fixes were developed by Dr Paul Dale. We are not aware of any working exploit that could lead to code execution, and we have no evidence of this issue being exploited as of the time of release of this advisory (November 1st 2022). X.509 Email Address Variable Length Buffer Overflow (CVE-2022-3786) === Severity: High A buffer overrun can be triggered in X.509 certificate verification, specifically in name constraint checking. Note that this occurs after certificate chain signature verification and requires either a CA to have signed a malicious certificate or for an application to continue certificate verification despite failure to construct a path to a trusted issuer. An attacker can craft a malicious email address in a certificate to overflow an arbitrary number of bytes containing the `.' character (decimal 46) on the stack. This buffer overflow could result in a crash (causing a denial of service). In a TLS client, this can be triggered by connecting to a malicious server. In a TLS server, this can be triggered if the server requests client authentication and a malicious client connects. OpenSSL versions 3.0.0 to 3.0.6 are vulnerable to this issue. OpenSSL 3.0 users should upgrade to OpenSSL 3.0.7. OpenSSL 1.1.1 and 1.0.2 are not affected by this issue. This issue was discovered on 18th October 2022 by Viktor Dukhovni while researching CVE-2022-3602. The fixes were developed by Dr Paul Dale. We have no evidence of this issue being exploited as of the time of release of this advisory (November 1st 2022). References == URL for this Security Advisory: https://www.openssl.org/news/secadv/20221101.txt Note: the online version of the advisory may be updated with additional details over time. For details of OpenSSL severity classifications please see: https://www.openssl.org/policies/secpolicy.html -BEGIN PGP SIGNATURE- iQJGBAEBCAAwFiEE3HAyZir4heL0fyQ/UnRmohynnm0FAmNhRdsSHHRvbWFzQG9w ZW5zc2wub3JnAAoJEFJ0ZqIcp55tARIP/R4TFlh4N3wH4enjT74oJowxjmwNIu0q uRTmmwtMwJOd1Nw0tfydVEtd3qaN/KMcMnnBMzIzvCdzQ202g8SRSzX7zeHZtAEe idu9qQyQep1ECK7UGybdN+4Ahey30Py6J99okWejCmdHSpxo7+OOtADFdraqrV5A 5vwyojD1Iv95Z0/RqYxMmMBEoJZitsGxeraw1IxBJCqw6sL2WwDelGb9NZwKFee1 BrfeF+dwaXlAZ97Hsaai6ssDf8VOoTNbCDsrsnbo4MAbFAc6ZraynMcWMm9kwF96 y+pO+0P9etzWeHkP+qHAeCCHZqU76Rexr58XtuWQpTdmbPbmLpnwr7wgwBAZxHA0 RkhpR244vPLYrF3cIssNxEstHCi2NFX0cMtOnbY84lJfmnxgHTJqH/7LvUmHibC6 FBNM9CCSezZgEiSvERB0R/auHZnpODj9riCyWWq82sXTkk3XrqkdnN3mAjgVpnDK 3Cacx9vJxpUDl2U4ObEVCE1I1qHKomAcKVAErAMmLLsdkbzoK9dUquG2VhFaJYJW 3TtqDMhQM0fqRgRu750P42w6dm1glH/UIK41viB0eVwbBZ0RdaAnI3+Tuk2NXH2o nZdH5Lx6scgS+l4K+IF2WzO+WCYThG0Sg22hC6NnFbdksoGA/XaXl80Kf5Ec1LJr QLeTSjQDj6Fc =8mrQ -END PGP SIGNATURE-
OpenSSL version 1.1.1s published
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenSSL version 1.1.1s released === OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 1.1.1s of our open source toolkit for SSL/TLS. For details of changes and known issues see the release notes at: https://www.openssl.org/news/openssl-1.1.1-notes.html OpenSSL 1.1.1s is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under https://www.openssl.org/source/mirror.html): * https://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-1.1.1s.tar.gz Size: 9868981 SHA1 checksum: d316e1523a609bbfc4ddd3abfa9861db99f17044 SHA256 checksum: c5ac01e760ee6ff0dab61d6b2bbd30146724d063eb322180c6f18a6f74e4b6aa The checksums were calculated using the following commands: openssl sha1 openssl-1.1.1s.tar.gz openssl sha256 openssl-1.1.1s.tar.gz Yours, The OpenSSL Project Team. -BEGIN PGP SIGNATURE- iQJGBAEBCAAwFiEE3HAyZir4heL0fyQ/UnRmohynnm0FAmNhEsESHHRvbWFzQG9w ZW5zc2wub3JnAAoJEFJ0ZqIcp55tB9sP/0xTGoi3fCQNWE3tq2iSLbhMeoXNSrnT kcKF98Dbzu1fuA+HRbb6rUr4Fnm8lp387cTM2ZQZQhpcMD8R16fwasZCkimaE64j o9Szand1G6OauVqUSCumzyM7ZEYg3PMvCwM9tOdZoUwxAt7cXagXEl8d+WDX9Xdm Gz8pAGTc2qk1oVfd25tBZkm6ievKq9a5B6QLmJdfYiycbRRLJV8bAcNrRNAy6EK/ aZDuQA7eYRgtg/K0LcwWKi0XYUT5zVTN1/GEEy4MzGASOw0UxWZ3B+gAje0bq2V0 3nt6+Ys/9THy418s3F16VRl9HiffZMICqDCPEYV7wQaKlm6dVTvc6kWQiGWR2C91 A1F/wOcvJzPuvNrqwwjmAzRJYdpyIS9FWhz39mOCbkm8C+ZAKyuhLzsZKeqDDGST oNgoIcc+ewn3O3ZKT65n7cgllvco2YpfIkdkh+afmhC8Jyy4wOpvA1qo5fQb20bk 2/K+qj+oLWSwqUzDQ14Lij3QY6p9IJY87dY8wIheJSAaGsRx+59JIlKuc7Y+QMah XJkugpXoht63j3phi8sDfz+be+oNNYNw9b43kkxPjT1T3403s5Eae3E8pPgj/ns3 12+nyNYe+e6O+i52QdjNVFG8DbIswrCWU2gm+5DZvd3ARffvWUykSZMuUGqz2d3R vlAteLLJJpw/ =ysWZ -END PGP SIGNATURE-
自动回复: Re: issue with 1.1.1n
这是一封自动回复邮件。已经收到您的来信，我会尽快回复。
Re: issue with 1.1.1n
On Tue, Nov 01, 2022 at 05:55:08AM -0500, Ray Crumrine wrote: > SSL SSL_ERROR_SSL (Handshake): Level: 0 err: <336151573> routines-ssl3_read_bytes-sslv3 alert certificate expired> Is this logged by the TLS client or server? In other words are you running a client application making outgoing connections or a server application receiving incoming connections? > but not all of the time. Only when I try to access > us-east-va.sip.flowroute using tlsv1.2. This sounds like "client". TLS alerts are sent by the other end of the connection, so if you're getting "certificate expired" alerts from a server, that means that your client is *sending* an expired certificate to the server (which must have solicited, possibly optional, client certificates). The server in question does send certificate requests: Transport Layer Security TLSv1.2 Record Layer: Handshake Protocol: Certificate Request (fragment) Content Type: Handshake (22) Version: TLS 1.2 (0x0303) Length: 16384 Handshake Protocol: Certificate Request (fragment) ... > I have tried two other sites using the same configuration and they work > fine. Is there a simple configuration change or do I need Openssl v3.0? The other sites presumably don't solicit client certificates. The simplest choice is to not configure a client certificate unless you're sure you're going to need one. > Checking with > https://decoder.link/sslchecker/us-east-va.sip.flowroute.com/5061 > everything checks fine??? The probe does not send expired client certs. -- Viktor.
OpenSSL version 3.0.7 published
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenSSL version 3.0.7 released == OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 3.0.7 of our open source toolkit for SSL/TLS. For details of the changes, see the release notes at: https://www.openssl.org/news/openssl-3.0-notes.html Specific notes on upgrading to OpenSSL 3.0 from previous versions are available in the OpenSSL Migration Guide, here: https://www.openssl.org/docs/man3.0/man7/migration_guide.html OpenSSL 3.0.7 is available for download via HTTPS and FTP from the following master locations (you can find the various FTP mirrors under https://www.openssl.org/source/mirror.html): * https://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-3.0.7.tar.gz Size: 15107575 SHA1 checksum: f20736d6aae36bcbfa9aba0d358c71601833bf27 SHA256 checksum: 83049d042a260e696f62406ac5c08bf706fd84383f945cf21bd61e9ed95c396e The checksums were calculated using the following commands: openssl sha1 openssl-3.0.7.tar.gz openssl sha256 openssl-3.0.7.tar.gz Yours, The OpenSSL Project Team. -BEGIN PGP SIGNATURE- iQJGBAEBCAAwFiEE3HAyZir4heL0fyQ/UnRmohynnm0FAmNhKfISHHRvbWFzQG9w ZW5zc2wub3JnAAoJEFJ0ZqIcp55tI3sP/0LX5X5pav+ajK9Vr0noUbAJwouA3YHi QMqkY30JjoUEc47PE2IJlEAObWebkeePz09UixdlNyQv/sZ8OdhKlDvzHJ1LxMM2 LfetggGkASQ4nQkjFxiyNDTdaP0feKQGzBfo/rjTz+H1plY7D6u7AtIeCnJW0qZX 7a4yzTV8FxEdHvr81XCYyYsuUlWYwoZk4iEstGR4jG4lzA12jh1DXuCfKhV6siTm 7530FQ4kid2R0eAwffiaZPPSG53AOUsRbc7M2xgjl3HKOdTCEIInwpVtUWqFOufo L/vkxjmFq8Xyq/DKUjCjcysiqX/Q4or0riMMzYkqqoIIQHGPyUrH7YvidEJ/ynPz BexjXLSFpx+McUxs711BR7p6pHOrp/Acu1619EKgzhVOGdgqxd3PW2/maVqx5YIZ ntsy5XNHE7UZ3tMTNz8gkVBAgZvQhl0YUN+LW5K6V/6VGxXqwFe6ZjyeyHvbv95J TRfZvC/T7ABmeWKAblQ5LL3EeLXyLSOL3mV/fp+dRNUyuFJFuHQmUTGFNRgx191c 2PbAbtHTd7Wihx4M/mEhRiklo/VQI9jdRq47yjtKgv6tji6+9v+txK7f7lMlVZP9 IxsHYgcomMo92vpj+FTCVQcOTXTiCfHi9A6PBSltd4sodMR2XxED44cNJ/FyJPj6 nuPkN6wv8d59 =9cNh -END PGP SIGNATURE-
issue with 1.1.1n
Hello, I have a strange issue with 1.1.1n. I am getting error SSL SSL_ERROR_SSL (Handshake): Level: 0 err: <336151573> routines-ssl3_read_bytes-sslv3 alert certificate expired> but not all of the time. Only when I try to access us-east-va.sip.flowroute using tlsv1.2. I have tried two other sites using the same configuration and they work fine. Is there a simple configuration change or do I need Openssl v3.0? Checking with https://decoder.link/sslchecker/us-east-va.sip.flowroute.com/5061 everything checks fine??? Any help appreciated.
Quantum-Resistant Cryptographic Algorithms
Will OpenSSL persue/support the four new NIST Quantum Cryptographic Algorithms? https://www.nist.gov/news-events/news/2022/07/nist-announces-first-four-quantum-resistant-cryptographic-algorithms
