
The secret message hidden in every HTTP/2 connection - jgrahamc
http://blog.jgc.org/2015/11/the-secret-message-hidden-in-every.html
======
jacquesm
In the communist days the writers of letters (in sealed envelopes) would
routinely greet the censor or wish them merry Christmas and stuff like that.

~~~
gvb
Feynman's version of messing with the censors:
[https://books.google.com/books?id=7papZR4oVssC&pg=PA114#v=on...](https://books.google.com/books?id=7papZR4oVssC&pg=PA114#v=onepage&q&f=false)

~~~
jacquesm
He came up with sending powder in envelopes? That's news to me.

The trick he played on Teller and then Teller seeing through it instantly,
priceless.

~~~
scintill76
I didn't quite get the desk/paper thing -- was it continuous feed paper, so
Feynman grabbed the end and pulled it all out?

~~~
jacquesm
No, he just kept on pulling and then another paper would be within reach until
the drawer just about emptied. Similar to how folded napkins are all separate
but you can pull one out of a container and then the next one will be pulled
into place by the previous one. That's on purpose and this is accidental but
the mechanism would be much the same.

------
mrb
"PRISM" is obviously a reference to the surveillance program. HTTP/2.0
developers were well aware and worried about it. For example see this mail
from PHK on the httpbis mailing list: [http://www.ietf.org/mail-
archive/web/httpbisa/current/msg142...](http://www.ietf.org/mail-
archive/web/httpbisa/current/msg14288.html)

~~~
noselasd
The HTTP/2 spec is done on
[https://github.com/http2/http2-spec](https://github.com/http2/http2-spec),
this particular change seem to be quietly introduced here:

    
    
        commit ac468f3fab9f7092a430eedfd69ee1fb2e23c944
        Author: Martin Thomson <martin.thomson@gmail.com>
        Date:   Fri Jun 14 13:14:02 2013 -0700
    
            Exercising editorial discretion regarding magic.
    
         diff --git a/draft-ietf-httpbis-http2.xml b/draft-ietf-httpbis-http2.xml
        index 58bbc27..f1e570d 100644
        --- a/draft-ietf-httpbis-http2.xml
        +++ b/draft-ietf-httpbis-http2.xml
        @@ -385,9 +385,9 @@ Upgrade: HTTP/2.0
                   The client connection header is a sequence of 24 octets (in hex notation)
                 </t>
                 <figure><artwork type="inline">
        -535441202a20485454502f322e300d0a0d0a52540d0a0d0a</artwork></figure>
        +505249202a20485454502f322e300d0a0d0a534d0d0a0d0a</artwork></figure>
                 <t>
        -          (the string <spanx style="verb">STA * HTTP/2.0\r\n\r\nRT\r\n\r\n</spanx>) followed by a
        +          (the string <spanx style="verb">PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n</spanx>) followed by a
                   <xref target="SETTINGS">SETTINGS frame</xref>.  The client sends the client connection header
                   immediately upon receipt of a 101 Switching Protocols response (indicating a successful
                   upgrade), or after receiving a TLS Finished message from the server. If starting an

~~~
mkjaer
The commit on GitHub, for anyone interested:
[https://github.com/http2/http2-spec/commit/ac468f3fab9f7092a...](https://github.com/http2/http2-spec/commit/ac468f3fab9f7092a430eedfd69ee1fb2e23c944)

~~~
djsumdog
Yea, looks like an inside joke / silent protest.

------
delibes
I had the pleasure of briefly working with Martin at LMAX. He definitely knows
how to get performance out of a system, and although it's not been updated
recently I'd recommend his old blog for those that haven't seen it yet and are
interested in where the nanoseconds go :

[http://mechanical-sympathy.blogspot.co.uk/](http://mechanical-
sympathy.blogspot.co.uk/)

~~~
wsargent
You're thinking of mjpt777.

------
wiredfool
Next up: a FOIA request for documents relating to the NSA's MOZILLA program in
the mid 1990s.

------
sandworm101
A funny joke, but a telling statement. Words so commonly used reflect
attitudes and history. For instance most of the English-speaking world says
Goobye ("God be with you") while the French use the more neutral AuRevoir
(until we see again). Web browsers now greet websites with "PRISM", the
equivalent of "the walls have ears".

------
zwischenzug
I blogged on the usefulness of reading RFCs more only the other day:

[https://zwischenzugs.wordpress.com/2015/11/26/the-it-
crowd-w...](https://zwischenzugs.wordpress.com/2015/11/26/the-it-crowd-was-
right-what-i-learned-by-reading-a-lot-of-rfcs/)

Personally, I trust the elders of the internet implicitly.

~~~
pdkl95
For wisdom from the "elders", I recommend reading RFC 1925.

[https://news.ycombinator.com/item?id=9045533](https://news.ycombinator.com/item?id=9045533)
(footnote [2])

------
spb
Great, so now all HTTP/2 traffic forever is going to start with a reference to
an NSA program that was topical for about a week in 2013.

Maybe we could have waited a year and made the magic

    
    
       THE * HTTP/2.0
    
       DRESS
    

Or if this change had been made a year earlier:

    
    
       KO * HTTP/2.0
    
       NY

~~~
thwarted
This is a pretty good way to remind ourselves ("Never Forget") why some things
are the way they are. It stands out and is perhaps unexpected, giving a chance
to have a discussion around the things we want to avoid or combat. That it
shows up in the protocol gives relevance to a FAQ entry on the topic, vs just
being a by-the-way FAQ entry that is easier to ignore.

It could just as well have been ECHELON [0], however PRISM has more recent,
and documented, meaning and more mindshare specifically around/related to
domestic spying.

[0]
[https://en.wikipedia.org/wiki/ECHELON](https://en.wikipedia.org/wiki/ECHELON)

------
gregory144
I named my hobby HTTP2 server after that string in the connection header:

[https://github.com/gregory144/prism-web-
server](https://github.com/gregory144/prism-web-server)

(obviously haven't had much time to work on it lately).

------
JoshTriplett
Leaving the specific letters aside, I wonder about this comment in
[https://github.com/http2/http2-spec/issues/101](https://github.com/http2/http2-spec/issues/101):

"And the experimental data we have (what there is of it) suggests that we need
to make this look like an unknown HTTP/1.1 method (or two)."

Anyone know what experimental data this refers to, and why this helps? This
gets encapsulated inside TLS; nothing should know about it except the
endpoints, both of which need to understand HTTP/2.

~~~
cesarb
HTTP/2 is not TLS-only, even though major browsers will only use it over TLS.
And even when over TLS, the TLS connection might terminate in a separate
machine, it going cleartext the rest of the way.

~~~
JoshTriplett
> HTTP/2 is not TLS-only, even though major browsers will only use it over
> TLS.

Which in practice will (hopefully) make it TLS-only. As I recall, one of the
original motivations to require TLS, and one of the reasons browsers plan to
mandate TLS (apart from the obvious), was specifically to avoid broken
"transparent" proxies.

> And even when over TLS, the TLS connection might terminate in a separate
> machine, it going cleartext the rest of the way.

If the server uses a TLS frontend device and passes cleartext to a backend,
then apart from that being a really bad idea from a security perspective, they
should know better than to allow that to pass through a broken transparent
proxy.

------
brbsix
Looking over [https://www.ietf.org/mail-
archive/web/httpbisa/current/msg14...](https://www.ietf.org/mail-
archive/web/httpbisa/current/msg14288.html), I'm not sure whether I'm reading
this correctly. In light of PRISM, the author posed a few options:

1) We can try to add more encryption to fight back.

2) We can recognize that there needs to be hooks for duly authorized access.

3) We can change or at least influence the political objectives

Personally, I'd have assumed option one is the obvious answer, in addition to
increasing adoption of encryption in other areas (though that may be outside
the scope of their project). Unfortunately the author seems to conclude that
there need to be (presumable CALEA-style) hooks for "duly authorized access".
This is almost unbelievable that they are openly suggesting implementing
backdoors in communications protocols. I expect this from LE and politicians,
but I don't expect this from FreeBSD commiters.

------
georgedrummond
This change was committed on Jun 14th 2013, about a week after the PRISM
programme had been leaked by Edward Snowden. It is a clear reference to the
programme but by this point it was already public knowledge.

I don't know the exact date that Snowden leaked PRISM but it was already being
talked about as early as June 6th 2013 in the Washington Post
[http://www.washingtonpost.com/wp-
srv/special/politics/prism-...](http://www.washingtonpost.com/wp-
srv/special/politics/prism-collection-documents/)

------
swayvil
It's a Pink Floyd reference, obviously.

~~~
icanhackit
Careful with that deep packet inspection, Eugene.

------
victorbojica
[http://gizmodo.com/what-is-prism-511875267](http://gizmodo.com/what-is-
prism-511875267) Maybe this ?

------
awjr
I can see pretty much why FUBAR was switched to -----. I'm more curious as to
what ----- stands for.

[Edit removed the secret message to keep the suspense ;)]

~~~
_bpo
"Planning Tool for Resource Integration, Synchronization, and Management"

~~~
_-__---
BACKwords-ly Reasoned-Out Name for Your Movement

------
kcorbitt
The author isn't implying that the NSA intentionally injected the word "PRISM"
into the header of every HTTP/2 connection. Rather, that the members of the
IETF that collaborated on the standard chose to change the existing dummy text
to match those initials once the existence of the program was leaked to the
public, presumably as a sort of inside joke/protest.

^ I figure I'd clarify that in case anyone else gets as confused as I did
about what possible political or technical objectives the NSA might achieve by
including a reference to a top-secret spy program in every HTTP/2 message
(although it does seem like the sort of thing a comic-book evil intelligence
organization would do :P).

~~~
platz
It seems like the thing an immature boy would do, but hey it just HTTP/2
protocol, no harm done!

~~~
antimagic
I downvoted you, but I thought I'd explain why - I don't think it's reasonable
to characterise this as childish. Government surveillance is something which
our industry is the best positioned to speak out against. This type of thing
seems to be clearly political speech, and not a prank.

~~~
Lawtonfogle
It also is something that really hurts our industry, perhaps more so than any
other industry out there.

Edit: To be clear, I mean the spying hurts our industry.

~~~
rand334
Yes; the entirety of our internet infrastructure is...almost...hopelessly
insecure. The OpenSSL team refuses to even use SSL/TLS on their website
because "they don't want anyone to get the slightest illusion that it's
secure" and want everyone to manually verify the SHA hashes.

~~~
simoncion
> The OpenSSL team refuses to even use SSL/TLS on their website because "they
> don't want anyone to get the slightest illusion that it's secure"

Eh?

1) Visting [http://www.openssl.org](http://www.openssl.org) automatically
redirects me to [https://www.openssl.org](https://www.openssl.org) .

2) The OpenSSL source code is stored in a git repo in GitHub. While this
doesn't _ensure_ that the code hasn't been tampered with, git _does_ make it
substantially easier to detect tampering than other VCSs do.

3) All of the release tarballs are PGP signed. Verification of the
authenticity of these files is just about as automatic as it gets.

~~~
loginusername
I could be mistaken but I think, not too long ago, openssl.org used to
redirect to openssl.net.

And if I recall correctly, it was [http://openssl.net](http://openssl.net) not
[https://](https://).

Is it possible there have been some changes in recent years?

~~~
simoncion
> Is it possible there have been some changes in recent years?

Well, I made my comment based largely on information that I verified a few
minutes before I wrote the comment. I'm unaware of the site's history.

------
mrdrozdov
The real gold is Ilya Grigorik's comment on the commit.
[https://github.com/http2/http2-spec/commit/ac468f3fab9f7092a...](https://github.com/http2/http2-spec/commit/ac468f3fab9f7092a430eedfd69ee1fb2e23c944#commitcomment-3430120)

------
mulle_nat
[https://en.wikipedia.org/wiki/Known-
plaintext_attack](https://en.wikipedia.org/wiki/Known-plaintext_attack)

~~~
hodwik
Care to explain the relevance?

~~~
pilsetnieks
The relevance is that this text could ostensibly be used as the known
plaintext to aid in breaking encryption, however, it's not going help much
anyway.

For example, with HTTP 1.1, it is pretty much likely that an HTTP response
would start with HTTP/1.1 200 OK, or that it would contain strings such as
"Content-Type" or "Content-Length". 24 more known bytes won't make it much
worse.

~~~
admax88q
Any strong cipher should be resistant to a known plaintext attack.

If your encryption is vulnerable to known plaintext you should upgrade.

