Re: [openssl-users] s_server -www -tls1_3: Firefox/Chrome not working
I suppose Facebook reports 50% because their mobile apps uses their SSL library Fizz with Tls 1.3 https://thehackernews.com/2018/08/fizz-tls-ssl-library.html I'm curious seeing your telemetry info now. Chrome 70 was released last week, and FireFox 63 today, with TLS 1.3 support regards Le mer. 12 sept. 2018 à 16:41, Viktor Dukhovni a écrit : > > > > On Sep 12, 2018, at 10:20 AM, Benjamin Kaduk via openssl-users < > openssl-users@openssl.org> wrote: > > > > IIUC, only Firefox nightly as of approximately today will support the > final > > RFC 8446 version; I haven't looked into Chrome yet. > > From the Firefox TLS 1.3 blog entry: > > > https://blog.mozilla.org/security/2018/08/13/tls-1-3-published-in-firefox-today/ > > What Now? > > TLS 1.3 is already widely deployed: both Firefox and Chrome have fielded > “draft” versions. Firefox 61 is already shipping draft-28, which is > essentially the same as the final published version (just with a different > version number). We expect to ship the final version in Firefox 63, > scheduled for October 2018. Cloudflare, Google, and Facebook are running it > on their servers today. Our telemetry shows that around 5% of Firefox > connections are TLS 1.3. Cloudflare reports similar numbers, and Facebook > reports that an astounding 50+% of their traffic is already TLS 1.3! > > -- > Viktor. > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] How to compile 1.1.1 under Windows
I am attempting to upgrade a project using OpenSSL 1.0.0h to version 1.1.1 under Visual Studio 2008-SP1, but when I try to compile version 1.1.1 for VC-WIN64A I get the following compile error: cl /Zi /Fdossl_static.pdb /Gs0 /GF /Gy /MD /W3 /wd4090 /nologo /O2 /I "." /I "crypto\include" /I "include" -D"L_ENDIAN" -D"OPENSSL_PIC" -D"OPENSSL_CPUID_OBJ" -D"OPENSSL_IA32_SSE2" -D"OPENSSL_BN_ASM_MONT" -D"OPENSSL_BN_ASM_MONT5" -D"OPENSSL_BN_ASM_GF2m" -D"SHA1_ASM" -D"SHA256_ASM" -D"SHA512_ASM" -D"KECCAK1600_ASM" -D"RC4_ASM" -D"MD5_ASM" -D"AES_ASM" -D"VPAES_ASM" -D"BSAES_ASM" -D"GHASH_ASM" -D"ECP_NISTZ256_ASM" -D"X25519_ASM" -D"PADLOCK_ASM" -D"POLY1305_ASM" -D"OPENSSLDIR=\"C:\\Program Files\\Common Files\\SSL\"" -D"ENGINESDIR=\"C:\\openssl\\lib\\engines-1_1\"" -D"OPENSSL_SYS_WIN32" -D"WIN32_LEAN_AND_MEAN" -D"UNICODE" -D"_UNICODE" -D"_CRT_SECURE_NO_DEPRECATE" -D"_WINSOCK_DEPRECATED_NO_WARNINGS" -D"OPENSSL_USE_APPLINK" -D"NDEBUG" /Zs /showIncludes "crypto\sm2\sm2_sign.c" 2>&1 > crypto\sm2\sm2_sign.d NMAKE : fatal error U1077: 'cl' : return code '0x2' Stop. NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\BIN\amd64\nmake.exe"' : return code '0x2' Stop. My Command lines from the VS 2008 x64 Command Prompt are: perl Configure VC-WIN64A --prefix=c:/openssl nmake I also tried compiling the latest stable snapshot (openssl-1.1.1-stable-SNAP-20181022) with the same results. However version 1.1.0h compiles without error. Can anyone tell me what the problem is? Here is the configuration dump: Command line (with current working directory = .): c:\perl\bin\perl.exe Configure VC-WIN64A --prefix=c:/openssl Perl information: c:\perl\bin\perl.exe 5.24.3 for MSWin32-x64-multi-thread Enabled features: aria asm async autoalginit autoerrinit autoload-config bf blake2 camellia capieng cast chacha cmac cms comp ct deprecated des dgram dh dsa dso dtls dynamic-engine ec ec2m ecdh ecdsa engine err filenames gost hw(-.+)? idea makedepend md4 mdc2 multiblock nextprotoneg ocb ocsp pic poly1305 posix-io psk rc2 rc4 rdrand rfc3779 rmd160 scrypt seed shared siphash sm2 sm3 sm4 sock srp srtp sse2 ssl static-engine stdio tests threads tls ts ui-console whirlpool tls1 tls1-method tls1_1 tls1_1-method tls1_2 tls1_2-method tls1_3 dtls1 dtls1-method dtls1_2 dtls1_2-method Disabled features: afalgeng[not-linux] asan[default] OPENSSL_NO_ASAN crypto-mdebug [default] OPENSSL_NO_CRYPTO_MDEBUG crypto-mdebug-backtrace [default] OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE devcryptoeng[default] OPENSSL_NO_DEVCRYPTOENG ec_nistp_64_gcc_128 [default] OPENSSL_NO_EC_NISTP_64_GCC_128 egd [default] OPENSSL_NO_EGD external-tests [default] OPENSSL_NO_EXTERNAL_TESTS fuzz-libfuzzer [default] OPENSSL_NO_FUZZ_LIBFUZZER fuzz-afl[default] OPENSSL_NO_FUZZ_AFL heartbeats [default] OPENSSL_NO_HEARTBEATS md2 [default] OPENSSL_NO_MD2 (skip crypto\md2) msan[default] OPENSSL_NO_MSAN rc5 [default] OPENSSL_NO_RC5 (skip crypto\rc5) sctp[default] OPENSSL_NO_SCTP ssl-trace [default] OPENSSL_NO_SSL_TRACE ubsan [default] OPENSSL_NO_UBSAN unit-test [default] OPENSSL_NO_UNIT_TEST weak-ssl-ciphers[default] OPENSSL_NO_WEAK_SSL_CIPHERS zlib[default] zlib-dynamic[default] ssl3[default] OPENSSL_NO_SSL3 ssl3-method [default] OPENSSL_NO_SSL3_METHOD Config target attributes: AR => "lib", ARFLAGS => "/nologo", AS => "nasm", ASFLAGS => "-g", CC => "cl", CFLAGS => "/W3 /wd4090 /nologo /O2", CPP => "\$(CC) /EP /C", HASHBANGPERL => "/usr/bin/env perl", LD => "link", LDFLAGS => "/nologo /debug", MT => "mt", MTFLAGS => "-nologo", RANLIB => "
Re: [openssl-users] What to do with deprecation errors
The "which package depends on which openssl ver" issue's been around a long time. FWIW, in general, I *never* touch openssl libs/headers in the default distro path, /usr. Just leave that alone -- too many distro packages (still) make (invalid) assumptions about that being the only/preferred openssl version. Also, some-not-all distros include /usr/local/ libs & headers in search path; with a higher priority than /usr. Drop the 'wrong version' there, and you can cause yourself similar headaches. Instead, I build openssl versions into standalone-dirs. E.g., /usr/local/openssl102 /usr/local/openssl110 /usr/local/openssl111 and then build any apps I want/need to use a specific version with appropriate CFLAGS/CPPFLAGS/INCLUDE, as well as LIBS with rpath. Yes, it's a slog. But for my use, it's been the only way to manage the mess. With the release of openssl 111, I suspect/hope things will begin to stabilize in app-land; but, I'm not holding my breath. And, of course, different strokes ... -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] What to do with deprecation errors
If the compiler found opensslconf.h in /usr/include/x86_64-linux-gnu/openssl/, that usually means you have an distribution openssl package installed, one that other programs are relying on. Depending on the version of that package, you may have screwed things up or not. If you're lucky, things will go smoothly, but be warning that your "installation" probably will get overwritten next time you do an update that affects the openssl package. For custom installations, I'd suggest using the /usr/local tree. This is what the default OpenSSL configuration + make install does. Cheers, Richard In message <1540233767.4886.24.ca...@taygeta.com> on Mon, 22 Oct 2018 11:42:47 -0700, Skip Carter said: > Found the problem! > Thanks to Selva for pointing the way. > > The compiler was looking for opensslconf.h (and only this file, not any > other header files) at /usr/include/x86_64-linux- > gnu/openssl/opensslconf.h when I copied > /usr/include/openssl/opensslconf.h to that location, everything worked. > The -E flag gave it away (it was buried in the cpp output too, but > was easy to miss). > > > On Mon, 2018-10-22 at 14:00 -0400, Selva Nair wrote: > > On Mon, Oct 22, 2018 at 1:51 PM Skip Carter wrote: > > > > > > Yes the macro is there, its just not being expanded by the pre- > > > compiler. > > > > All these tests say the same thing that you are picking up a wrong > > (old) header. > > > > So do: > > > > gcc -E your-program.c | grep opensslconf.h > > > > Then check whether the one it picks up is the right one and has > > the macro defined. > > > > Selva > -- > Skip Carter > Taygeta Scientific Inc. > -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] What to do with deprecation errors
Ah, I guess it wanted you to also compile OpenSSL for i386 and putting that (different!) opensslconf.h in the i386-specific directory. That also means you should have moved opensslconf.h to the subdir, not copied it. On 22/10/2018 20:42, Skip Carter wrote: Found the problem! Thanks to Selva for pointing the way. The compiler was looking for opensslconf.h (and only this file, not any other header files) at /usr/include/x86_64-linux- gnu/openssl/opensslconf.h when I copied /usr/include/openssl/opensslconf.h to that location, everything worked. The -E flag gave it away (it was buried in the cpp output too, but was easy to miss). On Mon, 2018-10-22 at 14:00 -0400, Selva Nair wrote: On Mon, Oct 22, 2018 at 1:51 PM Skip Carter wrote: Yes the macro is there, its just not being expanded by the pre- compiler. All these tests say the same thing that you are picking up a wrong (old) header. So do: gcc -E your-program.c | grep opensslconf.h Then check whether the one it picks up is the right one and has the macro defined. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] What to do with deprecation errors
Found the problem! Thanks to Selva for pointing the way. The compiler was looking for opensslconf.h (and only this file, not any other header files) at /usr/include/x86_64-linux- gnu/openssl/opensslconf.h when I copied /usr/include/openssl/opensslconf.h to that location, everything worked. The -E flag gave it away (it was buried in the cpp output too, but was easy to miss). On Mon, 2018-10-22 at 14:00 -0400, Selva Nair wrote: > On Mon, Oct 22, 2018 at 1:51 PM Skip Carter wrote: > > > > Yes the macro is there, its just not being expanded by the pre- > > compiler. > > All these tests say the same thing that you are picking up a wrong > (old) header. > > So do: > > gcc -E your-program.c | grep opensslconf.h > > Then check whether the one it picks up is the right one and has > the macro defined. > > Selva -- Skip Carter Taygeta Scientific Inc. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] What to do with deprecation errors
On Mon, 2018-10-22 at 17:52 +, Salz, Rich via openssl-users wrote: > > Yes the macro is there, its just not being expanded by the pre- > > compiler. > > That makes no sense. I am stumped, FYI here is the the relevant output of the precompiler (cpp) # 261 "/usr/include/openssl/ec.h" 3 4 DEPRECATEDIN_1_2_0(int EC_GROUP_set_curve_GFp(EC_GROUP *group, const BIGNUM *p, const BIGNUM *a, const BIGNUM *b, BN_CTX *ctx)) obviously when the actual compiler gets to this, its not happy. I have checked the precompiler version matches the compiler version. gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1) > Something is strange in your environment I am thinking the same but I haven't a clue what it is. I do lots of code development but this has me at a loss -- Skip Carter Taygeta Scientific Inc. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] What to do with deprecation errors
That's very odd. Are you *sure* the one you're looking at is the one actually included? Cheers, Richard In message <1540230631.4886.20.ca...@taygeta.com> on Mon, 22 Oct 2018 10:50:31 -0700, Skip Carter said: > Yes the macro is there, its just not being expanded by the pre- > compiler. > > > On Mon, 2018-10-22 at 08:55 +0100, Matt Caswell wrote: > > > > On 21/10/2018 20:01, Skip Carter wrote: > > > > Does your opensslconf.h have the DEPRECATEDIN_1_2_0 macro defined in > > it? > > > > Matt > -- > Skip Carter > Taygeta Scientific Inc. > > -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] What to do with deprecation errors
On Mon, Oct 22, 2018 at 1:51 PM Skip Carter wrote: > > Yes the macro is there, its just not being expanded by the pre- > compiler. All these tests say the same thing that you are picking up a wrong (old) header. So do: gcc -E your-program.c | grep opensslconf.h Then check whether the one it picks up is the right one and has the macro defined. Selva -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] What to do with deprecation errors
You're surely looking in the wrong header file. The compiler is using a different one in which the macro is NOT defined. > On Oct 22, 2018, at 1:50 PM, Skip Carter wrote: > > Yes the macro is there, its just not being expanded by the pre- > compiler. > > > On Mon, 2018-10-22 at 08:55 +0100, Matt Caswell wrote: >> >> On 21/10/2018 20:01, Skip Carter wrote: >> >> Does your opensslconf.h have the DEPRECATEDIN_1_2_0 macro defined in >> it? -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] What to do with deprecation errors
>Yes the macro is there, its just not being expanded by the pre- compiler. That makes no sense. Please look at your compiler manpages and figure out how to turn on verbose compiler output. Something is strange in your environment. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] What to do with deprecation errors
Yes the macro is there, its just not being expanded by the pre- compiler. On Mon, 2018-10-22 at 08:55 +0100, Matt Caswell wrote: > > On 21/10/2018 20:01, Skip Carter wrote: > > Does your opensslconf.h have the DEPRECATEDIN_1_2_0 macro defined in > it? > > Matt -- Skip Carter Taygeta Scientific Inc. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Reg issue in alert message
On 22/10/2018 14:56, ramakrushna mishra wrote: > Hi, > > I am facing an issue after openssl upgrade to 1.1.1. > I have a odbc client with maximum version support up to TLSv1.2 and my > database is running with TLSv1.2,TLsv1.3. > > The handhake is failing and I am getting following contents on my BIO dump. > "15 03 03 00 02 02 56" . > If i have understood correctly this is for alert message and But I could > not find any reference to alert description at ( > https://tools.ietf.org/id/draft-ietf-tls-tls13-25.html#alert-protocol ) > corresponding to 56. 56 hex == 86 decimal == inappropriate_fallback i.e. this doesn't tell you any further information than you have below. > > So, Could you please help me figure out what does this correspond to ? > > Moreover I have following doubt. > > -- If my TLSv1.2 client does not handle the "downgrade sentinel " > present in server hello ( TLSv1.3 , will it create any problem ? No, this should not be a problem. > -- In the above example client is receving error such as "SSL Handshake > Failure reason [error:1407743E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 > alert inappropriate fallback]." ? Could you please help me to hint me > about how to debug this ? What version of OpenSSL are you using for the client? Is it possible for you to send me a wireshark trace of the failing handshake? In particular I am interested to see if the TLS_FALLBACK_SCSV ciphersuite is present in the ClientHello (RFC 7507). The TLS_FALLBACK_SCSV is only supposed to be sent if the client has already attempted an earlier handshake that failed, and it is now trying a downgraded protocol version. So, does the wireshark trace reveal the client attempting an initial handshake that is failing for some other reason, followed by a second attempt that fails with the inappropriate fallback error? Matt -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Reg issue in alert message
Hi, I am facing an issue after openssl upgrade to 1.1.1. I have a odbc client with maximum version support up to TLSv1.2 and my database is running with TLSv1.2,TLsv1.3. The handhake is failing and I am getting following contents on my BIO dump. "15 03 03 00 02 02 56" . If i have understood correctly this is for alert message and But I could not find any reference to alert description at ( https://tools.ietf.org/id/draft-ietf-tls-tls13-25.html#alert-protocol ) corresponding to 56. So, Could you please help me figure out what does this correspond to ? Moreover I have following doubt. -- If my TLSv1.2 client does not handle the "downgrade sentinel " present in server hello ( TLSv1.3 , will it create any problem ? -- In the above example client is receving error such as "SSL Handshake Failure reason [error:1407743E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert inappropriate fallback]." ? Could you please help me to hint me about how to debug this ? Thanks and Regards, Ram Krushna -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] To disable CBC ciphers
On 20/10/2018 15:59, Kaushal Shriyan wrote: On Wed, Oct 17, 2018 at 7:00 PM murugesh pitchaiah mailto:murugesh.pitcha...@gmail.com>> wrote: Hi, You may list down what ciphers configured : "openssl ciphers" Choose CBC ciphers and add them to the list of 'ssl_ciphers' with "!" prefix appended to current ssl_ciphers. > ssl_ciphers HIGH:!aNULL:!MD5:!DH+3DES:!kEDH:!AAA_CBC_BBB: Ref: https://serverfault.com/questions/692119/meaning-of-ssl-ciphers-line-on-nginx-conf Thanks, Murugesh P. On 10/17/18, Kaushal Shriyan mailto:kaushalshri...@gmail.com>> wrote: > Hi, > > I have the below ssl settings in nginx.conf file and VAPT test has reported > us to disable CBC ciphers > > ssl_ciphers HIGH:!aNULL:!MD5:!DH+3DES:!kEDH; >> ssl_protocols TLSv1 TLSv1.1 TLSv1.2; > > > openssl version on the box is OpenSSL 1.0.2k-fips 26 Jan 2017 on CentOS > Linux release 7.3.1611 (Core) > > I will appreciate if someone can pitch in to help me understand to disable > CBC ciphers > Thanks Murugesh. I did checked openssl ciphers https://www.openssl.org/docs/man1.0.2/apps/ciphers.html and could not see !AAA_CBC_BBB as mentioned in your email. ssl_ciphers HIGH:!aNULL:!MD5:!DH+3DES:!kEDH:!AAA_CBC_BBB: Correct me if i am understanding it wrong. Basically i want to disable Cipher Block Chaining (CBC) mode cipher encryption. Openssl and OS version are as below :- openssl version on the box is OpenSSL 1.0.2k-fips 26 Jan 2017 on CentOS Linux release 7.3.1611 (Core) Any tools which i can run to find out vulnerabilities in the above openssl and OS version? Please guide and i look forward to hearing from you. Thanks in Advance. You need to replace AAA and BBB with actual strings corresponding to each of the unwanted cipher suites. The advisor that tells you to disable "CBC ciphers" is mostly wrong. There is nothing inherently bad about correctly using ciphers in CBC mode, however some TLS protocol versions happen to use CBC cipher suites in a problematic way, while having no secure non-CBC cipher suites. More recent TLS versions (such as TLS 1.2) have less problematic (but not perfect) CBC usage and also offers some overhyped US government ciphers such as the AES_GCM family. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] What to do with deprecation errors
On 21/10/2018 20:01, Skip Carter wrote: > Thats what I originally thought. > > I experimented with manually invoking the pre-compiler (cpp) and this > is what I get: > > > DEPRECATEDIN_1_2_0(int EC_GROUP_get_curve_GF2m(const EC_GROUP *group, > > BIGNUM *p, > BIGNUM *a, BIGNUM *b, > BN_CTX *ctx)) > the macro is not firing, shouldn't I get: > > extern int EC_GROUP_get_curve_GF2m(const EC_GROUP *group, > BIGNUM *p, > BIGNUM *a, BIGNUM *b, > > BN_CTX *ctx); > > > On Sun, 2018-10-21 at 18:28 +, Salz, Rich via openssl-users wrote: >>> And I still have the problem with those macros. >> >> >> The problem is almost definitely this: the files that you are >> compiling (not openssl) are picking up the wrong header files from >> openssl. >> Does your opensslconf.h have the DEPRECATEDIN_1_2_0 macro defined in it? Matt -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
