Bug in HTTP2 implementation on syndication.twitter.com


#1

Short version: I believe I’ve found a bug in the way the server that calls itself “tsa_a” at https://syndication.twitter.com implements RFC7540. It’s causing problems for the HTTP2 client software I’m writing because I’m checking for all the error conditions mentioned in the RFC and can’t connect to that server sometimes. Anybody has an idea where do I report this since it is not a security vulnerability and it’s nowhere near any of the categories mentioned at https://support.twitter.com/forms?

Long version: I have a pcap where after sending connection preface, my client creates a priority tree that includes streams 3, 5, 7, 9, 11. The streams are still in the idle state and the server doesn’t like this, so it goes on to close all of them with RST_STREAM message, code STREAM_CLOSED. This is actually a bad idea, since the RFC explicitly states that
" RST_STREAM frames MUST NOT be sent for a stream in the “idle” state.
If a RST_STREAM frame identifying an idle stream is received, the
recipient MUST treat this as a connection error (Section 5.4.1) of
type PROTOCOL_ERROR."
This means that a properly implemented HTTP2 client will sometimes be unable to connect to https://syndication.twitter.com.


#2

Thanks for this report.

One question I’d ask is under what circumstances you’re retrieving data from syndication.twitter.com - that is not a documented API endpoint, unless I’m missing something.

I’ll certainly mention this to some of my colleagues, but I cannot provide any specific timescales or roadmaps that would cover a resolution if we can reproduce this issue.


#3

I have no idea. The software I’m working on works more like a proxy, it just retransmits all browser’s requests. So the only thing I know for sure is that Firefox connects there when I open some web pages, e.g. http://cdr.cz/clanek/licencovana-hudba-pohrbila-hru-alan-wake-od-zitrka-se-nesmi-prodavat


#4

Thank you for the clarification.


#5

Can you tell us anything more about your software? We have had a similar report from a similar proxy tool.


#6

Is this the same as mitmproxy or is it alternative software? Thank you.


#7

It’s part of ESET Security’s Protocol filtering feature. I guess the idea is similar to mitmproxy, it does TLS MITM, intercepts HTTP2 requests and resends or modifies them as appropriate. The code base is in no way related though.


#8

Thanks again for clarification!


#9

To close this out (for now) - we are aware of the issue you’re reporting, and will work on it in the future, but there’s no timeframe on when this will be resolved at this time. Thank you.