Tls error--can someone explain it?

[Kevin Walzer]

The following code:

package require http
package require tls
::tls::init -ssl2 false -ssl3 false -tls1 true
::http::register https 443 ::tls::socket

set appname TextSweep
set versionurl https://www.codebykevin.com/$appname-version.tcl
set output [http::data [http::geturl $versionurl]]

puts $output

produces the following output:

SSL channel "sock7fddb50f1b10": error: tlsv1 alert protocol version
error reading "sock7fddb50f1b10": software caused connection abort
while executing
"http::geturl $versionurl"
invoked from within
"http::data [http::geturl $versionurl]"
invoked from within
"set output [http::data [http::geturl $versionurl]]"

This code is being run on Mac OS 10.12.3. I'm not familiar with the ins
and outs of Tls, so I'm not sure how to interpret this or what to do to
fix it. Can someone shed some light on this for me?

Thanks,
Kevin

--
Kevin Walzer
Code by Kevin/Mobile Code by Kevin
http://www.codebykevin.com
http://www.wtmobilesoftware.com

[Christian Gollwitzer]

Am 02.04.17 um 19:54 schrieb Kevin Walzer:

> ::tls::init -ssl2 false -ssl3 false -tls1 true

> produces the following output:
>
> SSL channel "sock7fddb50f1b10": error: tlsv1 alert protocol version
> error reading "sock7fddb50f1b10": software caused connection abort

Do you use the newest version of the TLS package? Roy Keene was updating
it with the most recent protocols. There have been some changes due to
security issues in different versions of the encrypted channels lately
(during the last year). AFAIK this is the current repo:
https://core.tcl.tk/tcltls/index

I am also not sure if it is advisable any longer to select the protocols
during tls::init

Christian

[kw]

I built and tested on macOS and it works fine. There doesn't seem to be a 64-bit Windows build anywhere. I'll have to figure that out separately unless I run across a Windows binary.

[Kevin Walzer]

On 4/2/17 10:12 PM, kw wrote:
> I built and tested on macOS and it works fine. There doesn't seem to be a 64-bit Windows build anywhere. I'll have to figure that out separately unless I run across a Windows binary.
>

As it turns out my Windows builds run just fine without updating...all
these changes appear to be in macOS. At least this reduces my workloads.
Thanks for the suggestion, Christian.

[Kevin Walzer]

Turns out I spoke too soon about it working. It works fine if run in
tclsh or if I run wish in the terminal. If I run it in a standalone app
bundle, there is a hard crash with this error:

Exception Type: EXC_BAD_ACCESS (SIGSEGV)

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libcrypto.1.0.0.dylib 0x000000010a34dbfd CRYPTO_get_ex_data
+ 13
1 tcltls.dylib 0x000000010a2d66c4 VerifyCallback +
84 (tls.c:277)
2 libcrypto.1.0.0.dylib 0x000000010a43c923 X509_verify_cert +
2259
3 libssl.1.0.0.dylib 0x000000010a312fcc
ssl_verify_cert_chain + 444
4 libssl.1.0.0.dylib 0x000000010a2ebc10
ssl3_get_server_certificate + 368
5 libssl.1.0.0.dylib 0x000000010a2ea633 ssl3_connect + 1971
6 libssl.1.0.0.dylib 0x000000010a2fac01 ssl23_connect + 3073
7 tcltls.dylib 0x000000010a2d7bcd Tls_WaitForConnect
+ 93 (tlsIO.c:230)

Sigh. The Windows build using tls 1.6.x has no problems at all. No clue
how to debug this because it runs in the debugger (lldb) and also runs
fine in the console.

--Kevin

[Erik Leunissen]

On 04/04/17 03:57, Kevin Walzer wrote:

[... snipped prequel]

>
> Turns out I spoke too soon about it working. It works fine if run in
> tclsh or if I run wish in the terminal. If I run it in a standalone app
> bundle, there is a hard crash with this error:
>
> Exception Type: EXC_BAD_ACCESS (SIGSEGV)
>
> Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
> 0 libcrypto.1.0.0.dylib 0x000000010a34dbfd
> CRYPTO_get_ex_data + 13
> 1 tcltls.dylib 0x000000010a2d66c4 VerifyCallback
> + 84 (tls.c:277)
> 2 libcrypto.1.0.0.dylib 0x000000010a43c923
> X509_verify_cert + 2259
> 3 libssl.1.0.0.dylib 0x000000010a312fcc
> ssl_verify_cert_chain + 444
> 4 libssl.1.0.0.dylib 0x000000010a2ebc10
> ssl3_get_server_certificate + 368
> 5 libssl.1.0.0.dylib 0x000000010a2ea633 ssl3_connect +
> 1971
> 6 libssl.1.0.0.dylib 0x000000010a2fac01 ssl23_connect +
> 3073
> 7 tcltls.dylib 0x000000010a2d7bcd
> Tls_WaitForConnect + 93 (tlsIO.c:230)
>
> Sigh. The Windows build using tls 1.6.x has no problems at all. No clue
> how to debug this because it runs in the debugger (lldb) and also runs
> fine in the console.
>

Seems like VerifyCallback() is passing something dirty to a function
inside the openssl libcrypto dll.

I'm unfamiliar with debugging under Mac OS (that's Mac OSX, I presume
?). Is there a lldb command to get a more detailed backtrace, equivalent
to the gdb command "bt full"?

Regards,
Erik Leunissen
--
elns@ nl | Merge the left part of these two lines into one,
xs4all. | respecting a character's position in a line.