HTTPS connections throw a segmentation fault about http-streams HOT 14 CLOSED

I also downgraded openssl from 1.0.1e1 to 0.9.8 and the program still segfaulted.

from http-streams.

My machine is a MacBook OS X 10.7.x running ghc-7.4.2

I also compiled it on another machine running FreeBSD 9.1 and ghc-7.4.1. Segmentation fault still occurred when attempting to request an https URI.

from http-streams.

I suspect this might have something to do with the use of unsafePerformIO and the creation of a global IORef instead of wrapping in a withOpenSSL; I'm going to re-wire some things to see if that is the case.

from http-streams.

It did not have anything to do with the global IORef. I removed all of it and I still receive the segfault - I'm now assuming the use of this:
SSL.contextSetDefaultCiphers ctx

Is the culprit - it might be trying to set a cipher for which newer version of openssl doesn't support? Not sure, digging into that.

from http-streams.

Okay it was none of those things.

A) The original implementation using IORef was wrong and it was causing it to crash on HTTPS because it was NOT wrapping withOpenSSL I figured this out after inspecting the stack from GDB and noticed there were threads blocking on FFI calls that I think led to the segfault.
B) withOpenSSL doesn't make the end-user use withOpenSSL if they are using the standard convenience functions unless they are setting up their own connection code; in which case use of withOpenSSL is encouraged to keep the unsafe computation "contained".

I'm submitting a pull request with my changes that fix this and clean up the usage of unsafePerformIO and IORef.

from http-streams.

So if I understand this correctly, the problem is that you are failing to call withOpenSSL in main? I'm pretty sure it is documented that you need to do so if making a request of an https URL, yeah?

The code that uses that IORef is (suppoed to be) lazy so if you're not using https then you should not hit any of it.

The default SSLContext is there so that we don't need separate get functions for http and https, which seems worth achieving in a convenience API.

AfC

from http-streams.

Yes I wasn't using withOpenSSL (I wasnt initially clear on that) in my main
but we don't need to. If you look at the diff where you're branching the
connection opener on whether the passed URI leads with http or https, the
do block is wrapped by withOpenSSL. So if you only ever pass an https
leading URI, SSL context won't be set up. I could be naive though. Please
inspect the code and let me know if I'm misunderstanding the code.
On Apr 2, 2013 8:38 PM, "Andrew Cowie" [email protected] wrote:

So if I understand this correctly, the problem is that you are failing to
call withOpenSSL in main? I'm pretty sure it is documented that you need
to do so if making a request of an https URL, yeah?

The code that uses that IORef is (suppoed to be) lazy so if you're not
using https then you should not hit any of it.

The default SSLContext is there so that we don't need separate getfunctions for http and https, which seems worth achieving in a convenience
API.

AfC

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/18#issuecomment-15813163
.

from http-streams.

I'm pretty sure you can only call withOpenSSL once. It'd be nice if it recorded internally whether it had been called or not (certainly my preferred pattern when writing C libraries), but at the moment it's quite an expensive call and reading its implementation it does a lot of work in native code. Probably best not to call it multiple times.

AfC

from http-streams.

That would make sense, it appears that's what they are saying in the docs too:
Computation of withOpenSSL action initializes the OpenSSL library and computes action.

from http-streams.

hs-tls looks like a more modern offerring than HsOpenSSL.

from http-streams.

@ixmatus you'll have to convince @gregorycollins of that; we've spoken about potentially using the tls package in the Snap Framework, but at the moment it is relatively unreviewed (and has had recent security flaws) and for production code you probably don't want to be relying on it; hence calling out to openssl.

AfC

from http-streams.

Fair enough and thanks for having this lengthy discussion w/ me. You can
close the pull request as I also now understand why you're doing it as you
are. Sorry to waste your time!
On Apr 3, 2013 3:58 AM, "Andrew Cowie" [email protected] wrote:

@ixmatus https://github.com/ixmatus you'll have to convince
@gregorycollins https://github.com/gregorycollins of that; we've spoken
about potentially using the tls package in the Snap Framework, but at
the moment it is relatively unreviewed (and has had recent security flaws)
and for production code you probably don't want to be relying on it; hence
calling out to openssl.

AfC

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/18#issuecomment-15825612
.

from http-streams.

Calling withOpenSSL is absolutely necessary because it initializes some things in the OpenSSL library. It's unfortunately not safe to call concurrently, because it mutates global data structures without taking a lock.

As for using some other library: there are unfortunately no credible and widespread alternatives :(

from http-streams.

I'm going to raise a bug on HsOpenSSL to see if we can't hold a lock & a boolean there to allow withOpenSSL to be re-entrant. I've done such things enough times in C code, so surely we can work something out.

AfC

from http-streams.