Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow configuration of how TLS should handle possible truncation attacks #235

Open
ktoso opened this issue Sep 12, 2016 · 1 comment
Open
Labels
1 - triaged Tickets that are safe to pick up for contributing in terms of likeliness of being accepted
Milestone

Comments

@ktoso
Copy link
Member

ktoso commented Sep 12, 2016

Issue by jrudolph
Tuesday Feb 10, 2015 at 15:16 GMT
Originally opened as akka/akka#16825


spray's latest version of SslTlsSupport is very strict in its handling of truncated messages. It turns out that there are several situations in combination with HTTP where some kind of truncation is likely to happen and produces warnings regularly. For https://groups.google.com/d/topic/spray-user/8FUAZ_QAfs4/discussion I made a quick test how current browser deal with potential truncation attacks and it seems that browsers are usually much more lenient than spray.

We should review that situation with akka-streams SSL implementation and maybe provide a configuration option about how to deal with possible truncation attacks.

See spray/spray#756.

/cc @sirthias

@ktoso ktoso added this to the http-backlog milestone Sep 12, 2016
@ktoso ktoso added the 1 - triaged Tickets that are safe to pick up for contributing in terms of likeliness of being accepted label Sep 12, 2016
@jrudolph
Copy link
Member

Right now the client-side just ignores truncations here:

val collectSessionBytes = b.add(Flow[SslTlsInbound].collect { case s: SessionBytes s })

We might want to add a paranoid mode that fails the stream if truncation occurs.

jrudolph added a commit to jrudolph/akka-http that referenced this issue Sep 11, 2017
…cenario

That is we are simulating a TLS truncation attack here. Before
akka/akka#21786 the TLS stage just got stuck
(I tested again an old Akka version).

Now, all streams are properly closed and also the response entity
stream is completed. A stricter version would actually fail the response
entity stream when TLS truncation is detected. If that is worthwhile is
actually questionable. See akka#235
for more information.
jrudolph added a commit to jrudolph/akka-http that referenced this issue Sep 11, 2017
…cenario

That is we are simulating a TLS truncation attack here. Before
akka/akka#21786 the TLS stage just got stuck
(I tested again an old Akka version).

Now, all streams are properly closed and also the response entity
stream is completed. A stricter version would actually fail the response
entity stream when TLS truncation is detected. If that is worthwhile is
actually questionable. See akka#235
for more information.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
1 - triaged Tickets that are safe to pick up for contributing in terms of likeliness of being accepted
Projects
None yet
Development

No branches or pull requests

2 participants