Uninformative handling of server aborting the SSL handshake

[nikita-volkov]

Here's a cURL session:

$ curl -v https://bigcinema.to:443
* Rebuilt URL to: https://bigcinema.to:443/
*   Trying 78.108.179.111...
* Connected to bigcinema.to (78.108.179.111) port 443 (#0)
* Server aborted the SSL handshake
* Closing connection 0
curl: (35) Server aborted the SSL handshake

And here's a TLS debug:

$ tls-simpleclient -d -v bigcinema.to 443
sending query:
GET / HTTP/1.0



debug: >> Handshake [ClientHello TLS12 (ClientRandom {unClientRandom = "\132\128\f\206\v\202\&9M\180h\240n\172\157\255\210\131\158)\150\144\202Z\229\158\237\243\234\b\DEL\STX\213"}) (Session Nothing) [49195,49196,49199,49200,158,159,49187,49188,49191,49192,103,107,49161,49162,49171,49172,51,57,156,157,61,60,53,47,56,50,10,5] [0] [ExtensionRaw 0 "000f00000c62696763696e656d612e746f",ExtensionRaw 65281 "00",ExtensionRaw 10 "0006001700180019",ExtensionRaw 11 "0100",ExtensionRaw 13 "001006010603050105030401040302010202"] Nothing]
debug: >> Alert [(AlertLevel_Fatal,InternalError)]
tls-simpleclient: Network.Socket.sendBuf: resource vanished (Broken pipe)

Can this be handled in a more informative way than thru the opaque "resource vanished" exception?

[ocheron]

It's not very clear what to expect as "more informative".

Your issue looks like a duplicate of #250, with a fix applied in #256 so HandshakeFailed exception is raised with a message mentioning a read issue instead of write (not yet released as of tls-1.4.0).

HandshakeFailed is likely to be handled better in caller code, it would be great if you can test and confirm that using unreleased development version.

"resource vanished" is actually how the condition is called internally in GHC:
https://github.com/ghc/ghc/blob/b938576d151731b85314987fc550c17cfe824178/libraries/base/GHC/IO/Exception.hs#L388