Re: LibreSSL 2.2 fails to connect to webdav.yandex.com
On Tuesday 09 June 2015, Alexey Ivanov wrote: On Jun 6, 2015, at 5:31 AM, Joel Sing j...@sing.id.au wrote: On Saturday 06 June 2015, 1edhaz+9sj4olxjt6...@guerrillamail.com wrote: Hello, LibreSSL 2.2 (openbsd-current) fails to connect to https://webdav.yandex.com. OpenSSL 1.0.1m from OpenBSD packages does succeed. Yandex is the largest search engine in Russia. The webdav.yandex.com site is for accessing their file-hosting service. System info: $ uname -a OpenBSD roger.my.domain 5.7 GENERIC.MP#1039 amd64 $ dmesg | head -n 1 OpenBSD 5.7-current (GENERIC.MP) #1039: Wed Jun 3 12:09:31 MDT 2015 [snip] The issue is due to the remote end not being RFC compliant and failing to complete a TLS handshake when it does not recognise TLS signature algorithms (sigalgs) that are being advertised by the client. In this case the new signature algorithms are related to GOST - almost the definition of irony... GOST… lol indeed =) If you want to verify this for yourself, you can comment out the GOST related entries in the tls12_sigalgs array in t1_lib.c. HTTPS connections to www.yandex.com work without issue, so it would seemingly be the particular HTTP server that is being used for this service - I would recommend contacting Yandex and reporting the issue to them. He just did - Yandex is heavy BSD user, so many people there are reading tech@ and freebsd-hackers@. Some brave souls even subscribed to trolls@^Wmisc@! Back to the problem itself, as far as I know they are aware of it. In the meantime, while they are busy solving it on their side, you may want to limit ciphersuites client is using by calling `SSL_CTX_set_cipher_list` before `SSL_do_handshake`. Except that would not have made any difference - currently the list of signature algorithms is static and not dependent on the cipher suites selected. PS. Anyway, next time you probably want to report libressl-related problems to recently announced libre...@openbsd.org [1]. [1] http://comments.gmane.org/gmane.os.openbsd.tech/42319 -- Action without study is fatal. Study without action is futile. -- Mary Ritter Beard
Re: LibreSSL 2.2 fails to connect to webdav.yandex.com
On Jun 13, 2015, at 4:00 PM, Joel Sing j...@sing.id.au wrote: On Tuesday 09 June 2015, Alexey Ivanov wrote: On Jun 6, 2015, at 5:31 AM, Joel Sing j...@sing.id.au wrote: On Saturday 06 June 2015, 1edhaz+9sj4olxjt6...@guerrillamail.com wrote: Hello, LibreSSL 2.2 (openbsd-current) fails to connect to https://webdav.yandex.com. OpenSSL 1.0.1m from OpenBSD packages does succeed. Yandex is the largest search engine in Russia. The webdav.yandex.com site is for accessing their file-hosting service. System info: $ uname -a OpenBSD roger.my.domain 5.7 GENERIC.MP#1039 amd64 $ dmesg | head -n 1 OpenBSD 5.7-current (GENERIC.MP) #1039: Wed Jun 3 12:09:31 MDT 2015 [snip] The issue is due to the remote end not being RFC compliant and failing to complete a TLS handshake when it does not recognise TLS signature algorithms (sigalgs) that are being advertised by the client. In this case the new signature algorithms are related to GOST - almost the definition of irony... GOST… lol indeed =) If you want to verify this for yourself, you can comment out the GOST related entries in the tls12_sigalgs array in t1_lib.c. HTTPS connections to www.yandex.com work without issue, so it would seemingly be the particular HTTP server that is being used for this service - I would recommend contacting Yandex and reporting the issue to them. He just did - Yandex is heavy BSD user, so many people there are reading tech@ and freebsd-hackers@. Some brave souls even subscribed to trolls@^Wmisc@! Back to the problem itself, as far as I know they are aware of it. In the meantime, while they are busy solving it on their side, you may want to limit ciphersuites client is using by calling `SSL_CTX_set_cipher_list` before `SSL_do_handshake`. Except that would not have made any difference - currently the list of signature algorithms is static and not dependent on the cipher suites selected. You are right indeed, my bad. The only other quick workaround that I can think of is to use TLS1.1 instead (if that’s acceptable from security standpoint): 훌 ~ echo -n | /usr/local/Cellar/libressl/2.1.6/bin/openssl s_client -connect webdav.yandex.ru:443 -tls1_1 | fgrep DONE DONE PS. Anyway, next time you probably want to report libressl-related problems to recently announced libre...@openbsd.org [1]. [1] http://comments.gmane.org/gmane.os.openbsd.tech/42319 -- Action without study is fatal. Study without action is futile. -- Mary Ritter Beard signature.asc Description: Message signed with OpenPGP using GPGMail
Re: LibreSSL 2.2 fails to connect to webdav.yandex.com
On Jun 6, 2015, at 5:31 AM, Joel Sing j...@sing.id.au wrote: On Saturday 06 June 2015, 1edhaz+9sj4olxjt6...@guerrillamail.com wrote: Hello, LibreSSL 2.2 (openbsd-current) fails to connect to https://webdav.yandex.com. OpenSSL 1.0.1m from OpenBSD packages does succeed. Yandex is the largest search engine in Russia. The webdav.yandex.com site is for accessing their file-hosting service. System info: $ uname -a OpenBSD roger.my.domain 5.7 GENERIC.MP#1039 amd64 $ dmesg | head -n 1 OpenBSD 5.7-current (GENERIC.MP) #1039: Wed Jun 3 12:09:31 MDT 2015 [snip] The issue is due to the remote end not being RFC compliant and failing to complete a TLS handshake when it does not recognise TLS signature algorithms (sigalgs) that are being advertised by the client. In this case the new signature algorithms are related to GOST - almost the definition of irony... GOST… lol indeed =) If you want to verify this for yourself, you can comment out the GOST related entries in the tls12_sigalgs array in t1_lib.c. HTTPS connections to www.yandex.com work without issue, so it would seemingly be the particular HTTP server that is being used for this service - I would recommend contacting Yandex and reporting the issue to them. He just did - Yandex is heavy BSD user, so many people there are reading tech@ and freebsd-hackers@. Some brave souls even subscribed to trolls@^Wmisc@! Back to the problem itself, as far as I know they are aware of it. In the meantime, while they are busy solving it on their side, you may want to limit ciphersuites client is using by calling `SSL_CTX_set_cipher_list` before `SSL_do_handshake`. PS. Anyway, next time you probably want to report libressl-related problems to recently announced libre...@openbsd.org [1]. [1] http://comments.gmane.org/gmane.os.openbsd.tech/42319 -- Action without study is fatal. Study without action is futile. -- Mary Ritter Beard signature.asc Description: Message signed with OpenPGP using GPGMail
Re: LibreSSL 2.2 fails to connect to webdav.yandex.com
On Saturday 06 June 2015, 1edhaz+9sj4olxjt6...@guerrillamail.com wrote: Hello, LibreSSL 2.2 (openbsd-current) fails to connect to https://webdav.yandex.com. OpenSSL 1.0.1m from OpenBSD packages does succeed. Yandex is the largest search engine in Russia. The webdav.yandex.com site is for accessing their file-hosting service. System info: $ uname -a OpenBSD roger.my.domain 5.7 GENERIC.MP#1039 amd64 $ dmesg | head -n 1 OpenBSD 5.7-current (GENERIC.MP) #1039: Wed Jun 3 12:09:31 MDT 2015 [snip] The issue is due to the remote end not being RFC compliant and failing to complete a TLS handshake when it does not recognise TLS signature algorithms (sigalgs) that are being advertised by the client. In this case the new signature algorithms are related to GOST - almost the definition of irony... If you want to verify this for yourself, you can comment out the GOST related entries in the tls12_sigalgs array in t1_lib.c. HTTPS connections to www.yandex.com work without issue, so it would seemingly be the particular HTTP server that is being used for this service - I would recommend contacting Yandex and reporting the issue to them. -- Action without study is fatal. Study without action is futile. -- Mary Ritter Beard
LibreSSL 2.2 fails to connect to webdav.yandex.com
Hello,
LibreSSL 2.2 (openbsd-current) fails to connect to https://webdav.yandex.com.
OpenSSL 1.0.1m from OpenBSD packages does succeed.
Yandex is the largest search engine in Russia. The webdav.yandex.com
site is for accessing their file-hosting service.
System info:
$ uname -a
OpenBSD roger.my.domain 5.7 GENERIC.MP#1039 amd64
$ dmesg | head -n 1
OpenBSD 5.7-current (GENERIC.MP) #1039: Wed Jun 3 12:09:31 MDT 2015
OpenSSL run:
$ eopenssl version
OpenSSL 1.0.1m 19 Mar 2015
$ echo -n | eopenssl s_client -debug -connect webdav.yandex.com:443
depth=1 C = PL, O = Unizeto Technologies S.A., OU = Certum Certification
Authority, CN = Certum Level IV CA
verify error:num=20:unable to get local issuer certificate
verify return:0
CONNECTED(0003)
write to 0xd6b51dc680 [0xd70e4f3000] (297 bytes = 297 (0x129))
- 16 03 01 01 24 01 00 01-20 03 03 8f 0d ed 87 39 $... ..9
0010 - 96 b6 31 ce a4 4a 01 e9-25 3a 03 96 75 54 60 d0 ..1..J..%:..uT`.
0020 - b9 9b 41 7a d1 af 6f 34-e7 bc 19 00 00 8a c0 30 ..Az..o4...0
0030 - c0 2c c0 28 c0 24 c0 14-c0 0a 00 a3 00 9f 00 6b .,.(.$.k
0040 - 00 6a 00 39 00 38 00 88-00 87 c0 32 c0 2e c0 2a .j.9.8.2...*
0050 - c0 26 c0 0f c0 05 00 9d-00 3d 00 35 00 84 c0 2f =.5.../
0060 - c0 2b c0 27 c0 23 c0 13-c0 09 00 a2 00 9e 00 67 .+.'.#.g
0070 - 00 40 00 33 00 32 00 9a-00 99 00 45 00 44 c0 31 .@.3.2.E.D.1
0080 - c0 2d c0 29 c0 25 c0 0e-c0 04 00 9c 00 3c 00 2f .-.).%/
0090 - 00 96 00 41 00 07 c0 11-c0 07 c0 0c c0 02 00 05 ...A
00a0 - 00 04 c0 12 c0 08 00 16-00 13 c0 0d c0 03 00 0a
00b0 - 00 15 00 12 00 09 00 ff-01 00 00 6d 00 0b 00 04 ...m
00c0 - 03 00 01 02 00 0a 00 34-00 32 00 0e 00 0d 00 19 ...4.2..
00d0 - 00 0b 00 0c 00 18 00 09-00 0a 00 16 00 17 00 08
00e0 - 00 06 00 07 00 14 00 15-00 04 00 05 00 12 00 13
00f0 - 00 01 00 02 00 03 00 0f-00 10 00 11 00 23 00 00 .#..
0100 - 00 0d 00 20 00 1e 06 01-06 02 06 03 05 01 05 02 ...
0110 - 05 03 04 01 04 02 04 03-03 01 03 02 03 03 02 01
0120 - 02 02 02 03 00 0f 00 01-01.
read from 0xd6b51dc680 [0xd675564000] (7 bytes = 7 (0x7))
- 16 03 03 00 57 02 W.
0007 - SPACES/NULS
read from 0xd6b51dc680 [0xd67556400a] (85 bytes = 85 (0x55))
- 00 53 03 03 55 72 4e 4e-f4 4b 58 3b 97 76 3a c0 .S..UrNN.KX;.v:.
0010 - 3a 70 e1 1e 7b d3 f7 51-39 c4 08 92 8b b0 d9 53 :p..{..Q9..S
0020 - 81 e4 b4 d8 20 0e 38 87-11 8b 29 e5 c3 05 e1 1f .8...).
0030 - 5b 5b 6f f6 a7 92 70 a5-ec 7c 28 80 ae 6b ba b0 [[o...p..|(..k..
0040 - 6b 90 d5 b9 06 c0 14 00-00 0b 00 0b 00 02 01 00 k...
0050 - ff 01 00 01
0055 - SPACES/NULS
read from 0xd6b51dc680 [0xd675564003] (5 bytes = 5 (0x5))
- 16 03 03 0a be.
read from 0xd6b51dc680 [0xd675564008] (2750 bytes = 1393 (0x571))
- 0b 00 0a ba 00 0a b7 00-06 78 30 82 06 74 30 82 .x0..t0.
0010 - 05 5c a0 03 02 01 02 02-10 69 d8 9e b2 4a ed e3 .\...i...J..
0020 - 01 8b dd 5e ae 9e d0 11-ea 30 0d 06 09 2a 86 48 ...^.0...*.H
0030 - 86 f7 0d 01 01 05 05 00-30 77 31 0b 30 09 06 03 0w1.0...
0040 - 55 04 06 13 02 50 4c 31-22 30 20 06 03 55 04 0a UPL10 ..U..
0050 - 13 19 55 6e 69 7a 65 74-6f 20 54 65 63 68 6e 6f ..Unizeto Techno
0060 - 6c 6f 67 69 65 73 20 53-2e 41 2e 31 27 30 25 06 logies S.A.1'0%.
0070 - 03 55 04 0b 13 1e 43 65-72 74 75 6d 20 43 65 72 .UCertum Cer
0080 - 74 69 66 69 63 61 74 69-6f 6e 20 41 75 74 68 6f tification Autho
0090 - 72 69 74 79 31 1b 30 19-06 03 55 04 03 13 12 43 rity1.0...UC
00a0 - 65 72 74 75 6d 20 4c 65-76 65 6c 20 49 56 20 43 ertum Level IV C
00b0 - 41 30 1e 17 0d 31 34 31-31 31 37 31 32 31 34 31 A0...14111712141
00c0 - 39 5a 17 0d 31 35 31 32-33 31 31 32 31 34 31 39 9Z..151231121419
00d0 - 5a 30 81 9c 31 0b 30 09-06 03 55 04 06 13 02 52 Z0..1.0...UR
00e0 - 55 31 13 30 11 06 03 55-04 0a 0c 0a 59 61 6e 64 U1.0...UYand
00f0 - 65 78 20 4c 4c 43 31 0c-30 0a 06 03 55 04 0b 0c ex LLC1.0...U...
0100 - 03 49 54 4f 31 0f 30 0d-06 03 55 04 07 0c 06 4d .ITO1.0...UM
0110 - 6f 73 63 6f 77 31 1b 30-19 06 03 55 04 08 0c 12 oscow1.0...U
0120 - 52 75 73 73 69 61 6e 20-46 65 64 65 72 61 74 69 Russian Federati
0130 - 6f 6e 31 19 30 17 06 03-55 04 03 0c 10 77 65 62 on1.0...Uweb
0140 - 64 61 76 2e 79 61 6e 64-65 78 2e 72 75 31 21 30 dav.yandex.ru1!0
0150 - 1f 06 09 2a 86 48 86 f7-0d 01 09 01 16 12 70 6b ...*.Hpk
0160 - 69 40 79 61 6e 64 65 78-2d 74 65 61 6d 2e 72 75 i...@yandex-team.ru
0170 - 30 82 01 22 30 0d 06 09-2a 86 48 86 f7 0d 01 01 0..0...*.H.
0180 - 01 05 00 03 82 01 0f 00-30 82 01 0a 02 82 01 01
