Data leakage between network streams with wai/warp/http-conduit about test-warp-wai

[snoyberg]

It would be a good idea to include a stack.yaml file so that everyone testing this is sure to be using the same library versions.

[snoyberg]

PR #2 adds a stack.yaml file so we can be sure we're all looking at the same thing.

[erikd]

I have a theory about this issue. My suspicion is that

• A TLS connection goes bad is terminated via an exception.
• The socket gets reused for a HTTP connection.
• The TLS finalizer gets run on the socket writing an alert packet.
• The HTTP response gets written on the socket.

Not sure if this scenario is even possible.

[snoyberg]

Funny you should mention that, I just got pinged with this:

snoyberg/http-client#225 (comment)

Sounds ominously familiar actually.

[cdepillabout]

Yup, this looks like the same bug I was seeing at snoyberg/http-client#225.

[erikd]

Confirmed. If I edit my canal file and set connection == 0.2.5.* and rebuild I cannot reproduce this issue. In addition, the HandshakeFailed messages that I was unsure about have disappeared. I don't get a single one!

[snoyberg]

Can you also try testing against this fix: snoyberg/http-client#226?

[erikd]

Will do! I assume that'a version of http-conduit and connection == 0.2.6.*?

[snoyberg]

Yes, that would be the idea. Though the patch in question only touch http-client, not http-conduit.

[snoyberg]

Here's an example of how to easily test this: yesodweb/shakespeare#194 (comment)

[erikd]

Doesn't seem to fix all of the issues.

Here's what I did (with connection == 0.2.6.*):

cabal sandbox delete
cabal sandbox init
git clone https://github.com/snoyberg/http-client
(cd http-client \
    && wget -O - https://github.com/snoyberg/http-client/pull/226.patch \
    | git am -s)
sed -i s/2.2.0.1/2.2.0.1123/ http-client/http-conduit/http-conduit.cabal
cabal sandbox add-source http-client/http-conduit
cabal install --dependencies-only

With that last line I watched the cabal install and noted that http-conduit-2.2.0.1123 was installed.

I then ran cabal build and ran the test in the Readme.md. I have managed to re-create all the issues I was concerned about including the leakage of TLS alert packets into the HTTP stream (on the 4th run of the test).

[snoyberg]

But you need to add http-client, not http-conduit.

[erikd]

I'll have to hack my code to use http-client.

[snoyberg]

No, it's used by http-conduit

On Fri, Sep 2, 2016, 1:37 PM Erik de Castro Lopo [email protected]
wrote:

I'll have to hack my code to use http-client.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#1 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADBB1bP0Zg-AKG-_k-eQazfdcmTO9Yrks5ql_xugaJpZM4JxN5E
.

[erikd]

My test was using HTTPS, which means I should switch to http-client-tls. Has that also been fixed?

[erikd]

So http-conduit uses http-client?

[snoyberg]

Yes

On Fri, Sep 2, 2016, 1:47 PM Erik de Castro Lopo [email protected]
wrote:

So http-conduit uses http-client?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#1 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADBB0F2-i93HYvxEgXeG7xjiGQ09fasks5ql_6vgaJpZM4JxN5E
.

[Yuras]

@erikd I was able to reproduce the issue in your test case. I got

dummy-https-server: HandshakeFailed (Error_Packet_Parsing "Failed reading: cannot decode alert level\nFrom:\talerts\n\n")

in three runs in a row.

After compiling via http-client with the patch applied, I don't see the error any more (tried 3 times). So I believe the patch fixes the issue.

[erikd]

Ok, I seem to have my test setup with the patched version of http-client.

I don't see the HandshakeFailed messages. That's good. However, I do see this message from the test-warp-wai process going into a failure state where it prints:

runHttpsClient : ConnectionFailure getProtocolByName: does not exist (no such protocol
name: tcp)

until terminated. This is due to file descriptor starvation.This did not happen with connection == 0.2.5.* even after running for over 5 minutes. With connection == 0.2.6.* and the patch, it was happening with about 2 minutes.

[snoyberg]

That sounds like a separate bug that should get opened against the
connection repo.

On Fri, Sep 2, 2016 at 2:30 PM, Erik de Castro Lopo <
[email protected]> wrote:

Ok, I seem to have my test setup with the patched version of http-client.

I don't see the HandshakeFailed messages. That's good. However, I do see
this message from the test-warp-wai process going into a failure state
where it prints:

runHttpsClient : ConnectionFailure getProtocolByName: does not exist (no such protocol name: tcp)

until terminated. This is due to file descriptor starvation.This did not
happen with connection == 0.2.5.* even after running for over 5 minutes.
With connection == 0.2.6.* and the patch, it was happening with about 2
minutes.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#1 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADBB7yPotjFP6VND55nzdZUlDQtw3E1ks5qmAjZgaJpZM4JxN5E
.

[dysinger]

I had the same experience with Amazonka. Sounds pretty related

[erikd-ambiata]

Data leakage has been fixed in (in think) tls.