00:00:00.167,00:00:06.106
>>So we are all set. Let's learn
about HTTP. Let's give our uh
rather nervous speaker a uh big

00:00:06.106,00:00:12.246
round of applause and make him
feel comfortable. [applause]
Have a good time you're gonna do

00:00:12.246,00:00:17.251
great. [applause] >>Okay so we
should add some demo but maybe
it won't works uh no demo.

00:00:21.188,00:00:26.193
[inaudible voices] Mic like this
okay. So it's Sunday morning and
I hope you are all well and I've

00:00:29.763,00:00:34.768
so this would be about HTTP. So
why wookiees um wookiees because
this is about smuggling and

00:00:40.274,00:00:45.279
wookiees are smugglers and the
also because the wookiee
language is a thing uh quite

00:00:49.349,00:00:55.055
hard to understand and easy to
misinterpret. So this was the
nice thing for HTTP so. So what

00:00:55.055,00:00:59.993
are we gonna talk about um
something about the eh HTTP that
you need to know uh what is HTTP

00:01:06.433,00:01:11.438
injection. Uh some recent some
some recent vectors HTTP 0 dot 9
which is on old versions uh

00:01:15.509,00:01:22.015
maybe not the demo you'd get to
trust me and then maybe we'd
talk about the tool I wrote

00:01:22.015,00:01:27.020
which is called HTTP Wookiee. So
who am I uh Regilero because
it's French. Um French um yes

00:01:32.426,00:01:38.365
it's that's Wookiee but maybe
sometimes you won't understand
my words. Uh I work I work on

00:01:38.365,00:01:44.838
the very small French uh free
software web company which is
called Makina Corpus. Uh 50

00:01:44.838,00:01:51.778
people I'm a devOp [mic boom]
I've always been a devop so it
means I'm a seasoned man and I'm

00:01:51.778,00:01:56.783
a developer. Um web security is
just a very small part of my job
and it's part of my spare time

00:01:59.753,00:02:04.691
or so. Sss and this is important
because if I can do it on my
spare time uh some other people

00:02:07.094,00:02:12.099
might be doing it uh better than
me. So why did I start testing
my tools uh I work every day

00:02:18.005,00:02:23.010
with open source HTTP servers
and I like this tools a lot um I
used to trust those tools a lot

00:02:28.215,00:02:33.220
but I found two very interesting
papers. The first one is HTTP
Host header real world attacks

00:02:35.756,00:02:42.696
and this is about uh very old
stuff in HTTP which is the
absolute [inaudible word] in

00:02:42.696,00:02:47.701
location. Um there's some tricks
with these so you can attack the
OS header on HTTP and the real

00:02:51.972,00:02:56.977
uh threats with this sort of
attacks um 2015 for example. The
other one is a study from 10

00:03:02.649,00:03:07.654
years ago 11 years ago which is
HTTP smuggling and everything is
inside. Most of the things I I

00:03:12.159,00:03:17.164
can tell you today are already
inside but it's like everyone
forgot it. So what is HTTP

00:03:22.302,00:03:27.307
smuggling uh it's a protocol
level attack so it's injection
on- everything always is

00:03:29.443,00:03:34.448
injection. Here we're gonna
inject HTTP in HTTP so we gonna
have more requests and more

00:03:39.286,00:03:44.291
responses than we should. And to
do this we'll craft low level
HTTP messages. By definition you

00:03:51.898,00:03:56.903
can not do this with the browser
on or on HTTP library because um
they do not make mistakes so the

00:04:01.708,00:04:06.713
goal here is to make mistakes
and when you make mistakes
usually you get errors but not

00:04:09.850,00:04:14.855
always. So before we start the
first things on HTTP is the very
old version of HTTP was one TCP

00:04:21.361,00:04:28.001
connection for each resource
like you want a file you want an
image you want CSS file you need

00:04:28.001,00:04:33.006
one new TCP/IP connection for
each resource then you do the
same- same act- act thing you

00:04:35.942,00:04:42.315
make your request you get your
response and then you try to
close the TCP/IP connection on

00:04:42.315,00:04:48.755
on their programs when you try
to close because we're not sure
you get there the answer and

00:04:48.755,00:04:55.328
this is a big personal scare of
course because you may need a
lot of TCP IP connections. So

00:04:55.328,00:05:00.267
they may keep alive on HTTP one
on one that is your we used the
same connection and when you get

00:05:02.969,00:05:07.474
the your response you can make
another request you get the new
response and you make another

00:05:07.474,00:05:12.479
request and you can infact you
can usually your browser will
use 6 TCP IP connection and do

00:05:15.715,00:05:20.720
this un unless you're you're
using HTTP 2 it's what you are.
Um there's also something that

00:05:26.426,00:05:31.431
most people doesn't know there's
pipelines so instead of waiting
for each response before doing

00:05:34.201,00:05:39.206
the next query you can send
every query and wait for the
every reponses. On the example

00:05:42.209,00:05:47.214
you can see that I made 4
queries and I get 3 responds
instantly which is a lot but the

00:05:50.116,00:05:55.121
important thing is the other
other responses so if one of the
response is huge you get to wait

00:05:58.758,00:06:03.697
for this response before having
the next one. So this is called
Head of line blocking and this

00:06:05.765,00:06:10.770
is also a preference program and
this is one of the reason of
HTTP 2 and the other reason of

00:06:12.939,00:06:17.944
HTTP 2 is smuggling because you
debug only on the other other
messages um um in HTTP 2 you've

00:06:25.051,00:06:30.056
got a real binary multiplexing
thing where each response can be
accelerated with the request on

00:06:32.959,00:06:37.964
it it's better. If you get a
reverse proxy like a [inaudible
word] or reverse proxy cache uh

00:06:41.901,00:06:48.808
the things if you make by
applying to the reverse proxy
will talk to the back end

00:06:48.808,00:06:53.813
without the pipeline it will
make just a simple um HTTP 1 dot
0 or 1 dot 1 keep alive

00:06:57.617,00:07:03.657
connection but you will not
choose a pipeline when you talk
to the back end. The problem is

00:07:03.657,00:07:08.662
the back end doesn't know that
there's no pipeline. So if you
can make the reverse proxy play

00:07:11.932,00:07:18.571
something which looks like a
pipeline the back end may cease
all requests and send several

00:07:18.571,00:07:23.576
response but the reverse proxy
doesn't want several responses.
This is smuggling um you've got

00:07:29.249,00:07:34.254
one example here where I send
something which should be only
one query but the final um step

00:07:39.893,00:07:45.665
has a split splitting issue so
now you've got 2 queries and
you've got one extra response

00:07:45.665,00:07:50.970
and the problem is on the
question mark. What do you do
when you've got one extra

00:07:50.970,00:07:57.477
response and you've got 2 type
of things with are the
transmitter which transmit the

00:07:57.477,00:08:02.415
bad syntax and you've got the
splitter which splits on this
bad syntax on the 2 are problem

00:08:05.785,00:08:10.790
problems but the spitter is the
real problem. So why do you do
HTTP smuggling maybe just

00:08:14.561,00:08:19.566
because you want to hide a query
so maybe the reverse proxy would
like to prevent this sort of

00:08:22.135,00:08:27.140
query to happen but it doesn't
see the query. Uh you can make
crash you can crash a lot of

00:08:29.376,00:08:34.381
things when bad syntax are used.
You can try to shift the
response trim like uh if you

00:08:38.685,00:08:45.592
insert one extra response on the
pipeline you may really shift
the ruh the stream and do cache

00:08:45.592,00:08:50.597
poisoning and you may also try
to attack another user
credentials on HTTP by using

00:08:52.766,00:08:57.771
incomplete queries and this is
uh thing on the on the
demonstration. All those things

00:09:00.340,00:09:05.345
were described 2005 already. So
we also need exploit oh. Hmm hmm
it's not me. [laughing] It's the

00:09:19.859,00:09:24.864
mic. [mic boom] [knocking] It's
my day. [applause] thanks ab
[applause] So the exploits it's

00:09:51.057,00:09:56.062
all about size because we are in
a pipeline we have got we've got
several messages in the pipeline

00:10:03.870,00:10:08.875
and each one has it's own size
so the goal is to alter alter
the size. You can make double

00:10:11.911,00:10:17.217
content length headers so people
doesn't know which is the right
one and this is strictly

00:10:17.217,00:10:23.256
forbidden. You can play with
content length and chunked
transmission and you should not

00:10:23.256,00:10:28.261
play with both. Um on chunked
transmission you do not have a
line for your message you say I

00:10:30.897,00:10:36.536
will send things and when you
see the end of chunk marker it's
the end of the message. Uh you

00:10:36.536,00:10:42.175
could use inverted errors or
inverted values like the
contents length with a space is

00:10:42.175,00:10:47.180
not a valued error. Uh you could
use also invalid LF lines like
the first one the real LF line

00:10:51.918,00:10:56.923
is CR LF you could try to use LF
or so it's almost valued but CR
is not valued as an LF line. Um

00:11:02.262,00:11:07.267
you could also try to use very
old features of HTTP which are
still there like HTTP 09 like uh

00:11:12.305,00:11:17.310
multiline errors which are in
the RFC. So the first demo um at
least you can read the the thing

00:11:25.718,00:11:30.723
um ya these should make an
attacking credential exploit. So
here you've got some real world

00:11:34.027,00:11:39.032
uh exploitation like this was
working on nod before the
version 5 but 6 it's a splitting

00:11:41.834,00:11:46.839
issue and you should always have
CRLF format for LF line but for
node if you are the CR they fold

00:11:53.346,00:11:58.351
that they do not treat need to
read the next character because
it's always RF but if it's not

00:12:01.654,00:12:06.659
you've got to program so on on
the example you've got the dummy
header and then you got the CR

00:12:09.629,00:12:14.634
on a zid corrector which is not
an LF and any other thing so for
everybody this is just one

00:12:16.769,00:12:21.774
header which is dummy header CR
zed transfer-encoding it means
nothing but for node there are 2

00:12:24.877,00:12:31.517
headers. The first one is dummy
header which means nothing and
there's a transfer-encoding

00:12:31.517,00:12:36.522
header. So for everybody this
request is one request on the in
blue. You've got the body of the

00:12:39.125,00:12:45.598
request and you can make a get
request with the body it's
allowed. So this is just one

00:12:45.598,00:12:50.603
request with a binary body that
nobody reads but for Node you've
got transfer encoding chunked

00:12:54.574,00:12:59.579
and there's a pre priority and
chunked always has the priority
on content length So it does it

00:13:03.383,00:13:08.388
does not read content length it
reads chunked on the first bytes
of the body is the LF chunk

00:13:12.625,00:13:17.630
marker so after the LF chunk
marker you've got a new request
in the pipeline. You've got a

00:13:21.034,00:13:26.039
past request and this past
request is please select user 2
um there's another thing on on

00:13:31.577,00:13:36.582
this second request. There's a
partial there's a partial LR at
the end so um it's an

00:13:39.118,00:13:44.123
unterminated past request. Node
is still waiting for the end of
this request. So what could

00:13:51.531,00:13:56.536
happen if you got a reverse
proxy in front of Node with a
keep alive connection with node

00:14:01.274,00:14:07.680
and the first proxy get the
first response like he think
he's thinking this is one query

00:14:07.680,00:14:12.685
I need one response so you get
one response. Then Node is just
wait waiting for a second query

00:14:15.354,00:14:20.359
and another user like the admin
user is there sends a query any
query and the query gets

00:14:22.695,00:14:27.700
appended to the int unterminated
one. With the new user
credentials like the cookie like

00:14:33.840,00:14:38.845
an HTTP authentication
credential and then the admin
user is doing a post user edit

00:14:41.814,00:14:46.819
to without requesting it. So uh
I cannot show you because there
are problems with the screens

00:14:51.791,00:14:56.796
but atleast I can show you uh
what happens um I'm the attacker
uh I send a request to vanish

00:15:01.734,00:15:07.940
which is which is a reverse
proxy cache on this request is
the request you just so like

00:15:07.940,00:15:12.945
you've got infact 2 requests but
it's just one and the request
goes to Node. Node has a

00:15:15.648,00:15:20.653
splitting issue so is un a know
things there are 2 requests and
it sends back 1 reasons then

00:15:24.457,00:15:29.462
another user came for um new
request which is request C
vanish reuse a keep alive

00:15:35.401,00:15:41.541
connection with a back end so
send the request C which is
appended to the unterminated

00:15:41.541,00:15:46.546
request and then it get response
B which was my hidden request um
the user 2 is the [inaudible

00:15:51.717,00:15:56.722
word] uh only if you do not have
um CS CR perfection on the past
request. So this is a way to run

00:16:02.395,00:16:07.400
this attack it's just a request
I run it uh on the nukes with a
printer from net cat just to put

00:16:10.770,00:16:15.775
the contents in it's P IP
connection when I do it uhh 150
time just to feel every vanish

00:16:19.345,00:16:24.350
um dis P IP connection in the
pool of backend connection with
the node and it works. Believe

00:16:27.954,00:16:34.293
me make you can try you've got
everything on on the CD if you
want to try. It it worked um

00:16:34.293,00:16:39.298
before it was fixed on Node. Um
there was a second demo and on
this one is about IH HTTP 0 dot

00:16:47.540,00:16:52.545
9. So HTTP 0 dot 9 is something
awful which should not exist. Uh
it was the very very first

00:16:56.616,00:17:01.554
version of HTTP where you do not
have any errors so you've got an
example of what is HTTP 0 dot 9,

00:17:05.258,00:17:11.964
1 dot 0 and 1 on 1. On 0 dot 9
you do not have the the protocol
version you just the middle on

00:17:11.964,00:17:16.969
the location. Noid errors. Noid
errors it means there's some
noid errors on the response but

00:17:20.039,00:17:26.512
the security of HTTP's and the
errors like the content eye of
the cookies the content security

00:17:26.512,00:17:32.451
policies the content length
everything is on the errors. On
HTTP 0 dot 9 you've got just the

00:17:32.451,00:17:37.456
body of the answer. So it's just
text stream and if you get a
text stream maybe you can make

00:17:41.460,00:17:46.465
this text stream look like a
real HTTP response with errors.
So for example you can make an

00:17:49.402,00:17:54.407
image and the content of the
image instead of being a binary
thing would be uh an HTTP

00:17:57.310,00:18:02.248
response with errors and if you
requested this image in 0 dot 9
mode it may looks like an HTTP

00:18:05.351,00:18:10.356
response. You can also try to
hide uh these parts this HTTP
may say each in the exit data of

00:18:13.960,00:18:20.266
the image and make it one large
query to only get this part of
the image. So you get your real

00:18:20.266,00:18:25.271
image and if you request for un
un the the right parts of the uh
image. You've got arrange HTTP

00:18:28.040,00:18:33.045
response but you should not be
able to do a range request in
HTTP 0 dot 9 mod. So another

00:18:37.116,00:18:42.121
another program uh is the node
cache poisoning like maybe you
know about cache poisoning in

00:18:44.657,00:18:49.662
HTTP but for cache poisoning you
need the cache. Note cache
poisoning it is infact circuit

00:18:52.398,00:18:57.403
poisoning like take TCP PTC IP
circuits and you add response on
their circuits and another user

00:19:01.040,00:19:06.045
when the circuit is reused get
the response. So this is a real
thing on Apache for example. So

00:19:12.518,00:19:17.523
this was the thing we could try
like here we've got uh a
splitting issue on go uh where

00:19:21.761,00:19:26.766
gogh uh is fixing your uh your
syntax like transfer cutting
with a space is fixed as

00:19:30.536,00:19:35.541
transfer dash uncutting. Uh so
for everyone uh the line
transfer cutting chunked means

00:19:39.011,00:19:44.016
nothing but for go it's a real
line so same as before the blue
part uh is no new request and

00:19:48.187,00:19:53.192
there's the note cache poisoning
we'll use it. Uh there's another
bag on uh go which is that we

00:19:56.896,00:20:01.901
can ask for HTTP 0 dot 9 which
does not exist and this makes 0
dot 9 crash. It should not work

00:20:05.037,00:20:11.711
this way and there's a third bug
on the go where we can make a
range query in 0 dot 9 model. It

00:20:11.711,00:20:16.715
should not exist because in 0
dot 9 mod we should not rid the
request errors. So you make your

00:20:20.486,00:20:25.491
request uh with a splitting
issue on the go long reverse
proxy for some pro ya I've got

00:20:27.593,00:20:32.598
an Ipa Apache reverse proxy
which transmit the request to
go. I've got a splitting issue

00:20:34.934,00:20:39.939
on go so go is doing this
request um uh against Nginx it
targets an image and takes only

00:20:49.648,00:20:54.653
their HTTP part of this image
which gets back in HTTP 1 dot 1
mod but for go it's in the HTTP

00:20:58.991,00:21:04.396
0 dot 9 request so it removes
the errors of the originals and
sends you back the real thing.

00:21:04.396,00:21:09.401
Uh it's hard to understand
without the demonstration but it
works it means I can um request

00:21:13.506,00:21:18.511
with go an HTTP response which
is you know in an image on a
server. Um in inject this

00:21:20.813,00:21:25.818
response on the streams of fresh
ones but there's another problem
for Apache if we get back there

00:21:28.654,00:21:33.659
was only one request and it
get's one response. Then there's
a new response which carries

00:21:35.895,00:21:40.900
back which was the response in
the in the image and for Apache
there's nothing to do with this

00:21:43.269,00:21:48.274
response so nothing's happened
and the response is stored on
the TCP IP connection. The when

00:21:52.411,00:21:57.416
a new request is coming for
Apache from anybody Apache will
use the TCP IP connection with a

00:22:00.886,00:22:07.726
back end send a new request on
the read on the TCP IP
connection to see maybe I've I

00:22:07.726,00:22:14.200
have an response in file and you
see that the other response
takes and send it back to the

00:22:14.200,00:22:21.207
user just before getting the
real response which was hey no
you should not reuse this

00:22:21.207,00:22:28.013
connection. This is an er errors
T on TCP IP because there was a
0 dot 9 response so you should

00:22:28.013,00:22:33.018
not reuse the connection but
it's too late. The the the
message was told and was sent

00:22:36.188,00:22:41.193
back to the user. So you can
store a response in Apache and
get this response with maybe an

00:22:44.029,00:22:50.603
nexuses or maybe everything you
want like any error you want any
cut on security policy error and

00:22:50.603,00:22:55.608
sending back to every user. So
this is the way to do it if you
want. You need to run a lot of

00:22:58.877,00:23:03.816
requests because you need to
feed every TCP IP connection and
um I cannot show show it to you

00:23:07.786,00:23:12.791
but it works. Um what can I say
about it. The real problem on
these things are the splitting

00:23:18.464,00:23:23.469
issues and if we get back just
right here. Here this is the
real problem on go and it's

00:23:31.110,00:23:36.115
fixed now. Uh as soon as you
have a splitting issue bad
things happens like having an

00:23:38.183,00:23:44.657
extra response sent back and for
Apache the fact that you've got
the note cache poisoning is a

00:23:44.657,00:23:49.662
public issue it's not a security
is-issue because they consider
that there was a security issue

00:23:52.131,00:23:57.136
for go there was a splitting
issue and what happens after
that is not there problem. It's

00:23:59.571,00:24:04.510
a little their problem but it's
complex to manage if you think
that uh uh the the back end is

00:24:07.813,00:24:12.818
doing bad things you cannot do
anything. So for every splitting
issue you should a CVE because

00:24:18.190,00:24:23.195
for me it's quite critical uh
but usually projectly theirs do
not like uh doing CVE on those

00:24:25.864,00:24:31.870
things and maybe sometimes they
do not understand oh you can
exploit the the injection and

00:24:31.870,00:24:36.875
because of so they do not want
people to try to do things uh
with those issues. The other

00:24:40.546,00:24:45.551
ish- issues are transmission of
the st-strong syntax like ya I
had something which is quite

00:24:48.721,00:24:54.493
very strong syntax like transfer
encoding with a space. You
should not have any header with

00:24:54.493,00:24:59.965
a space in the in the header
title and a reverse proxy could
detect that this header is

00:24:59.965,00:25:04.970
invalid and could reject your
query but usually they do not do
this. So there's a big problem

00:25:11.110,00:25:16.115
of responsibility because
everyone is trusting every other
one and no one wants to take the

00:25:19.418,00:25:24.423
full responsibility of the
problems on things which looks
like smaller things. For

00:25:27.326,00:25:32.331
security researcher and a
warning, you will not earn money
with uh HTTP smuggling because

00:25:34.700,00:25:39.705
you cannot test it uh like an
XSS thing you cannot take a
public infrastructure and try to

00:25:43.509,00:25:48.514
break everything because you
won't be the only one impact
impacted on this. You may crash

00:25:50.783,00:25:55.788
everything you may send back
response through people that
have nothing to do with you so

00:25:58.057,00:26:02.995
it's very hard to test on public
uh servers. Um I earned one uh
brain teaser with a golang issue

00:26:08.133,00:26:13.138
uh from Google but it was ruh
unexpected and it's very hard to
usually explain to people that

00:26:16.675,00:26:21.680
maybe they should upgrade their
servers. Um the other things is
that we should have more people

00:26:23.916,00:26:28.921
written the code of HTTP servers
like there are a lot of issues
which are still there and we

00:26:31.290,00:26:36.295
need people which really do not
trust blindly the code. Um
things get better um years after

00:26:42.434,00:26:47.439
years the issue gets fixed and
you should really try to upgrade
um to avoid problems. Some other

00:26:52.544,00:26:59.184
exploits may be because we
cannot see them all so we
content time on exploits. Uh I

00:26:59.184,00:27:04.122
had some expression Nginx links
like their integral over flows.
This cannot be used with Nginx

00:27:07.092,00:27:12.097
as a reverse proxy but if you
got Nginx as a back end you can
try some things with uh very low

00:27:14.600,00:27:19.605
numbers. This was fixed last
year and there is another issue
which is fixed on the chunked

00:27:21.874,00:27:26.879
currently which is a 0 dot 9
downgrade using HTTP 65536 dot 9
or dot 8 where you can even use

00:27:31.717,00:27:33.719
a post and this is uh 0 dot 9
query for Nginx so you get no
errors in the response. This is

00:27:33.719,00:27:35.721
usually wer -er not transmit
transmitted by your reverse
proxy to Nginx. Like you need to

00:27:35.721,00:27:40.726
to exploit these sort of things
you need to get Nginx as a back
end and you need the re-reverse

00:27:54.673,00:27:59.678
proxy which transmit this bad
syntax and this usually doesn't
happen but in the past HP proxy

00:28:01.647,00:28:06.652
was transmitting these to Nginx
and HP proxy is one of the best
HTTP tools against smuggling. Um

00:28:13.625,00:28:18.630
another one here it's a CR
against vanish uh we air the
CRLF line was varied and you

00:28:22.367,00:28:28.240
could also use the double
content figures and there's
another one but I can't remember

00:28:28.240,00:28:33.245
what what what I can't read
another one on Apache like here
it's on the chunked size

00:28:36.848,00:28:41.853
attributes so when you do
chunked transmission you've got
chunks with a size on there was

00:28:44.323,00:28:49.328
a truncation like only the 31
first cu-characters here are
reads. So you can use the work

00:28:51.730,00:28:56.735
like that and try to alter the
size of the chunks this is now
fixed of course um there are the

00:29:00.305,00:29:05.310
other exploits I showed
previously in go in Apache like
the note cache poisoning in Nod

00:29:09.247,00:29:14.252
and there's also various peoples
other peoples we fix which fix
overflows like we had in one the

00:29:17.656,00:29:22.661
Python U UR lead recently and uh
another overs so do you protect
again lease the first thing is

00:29:30.402,00:29:35.407
to use the last RFC which is uh
72 30 and a lot of people are
still using the very old RFC 4

00:29:38.610,00:29:43.615
HTTP 1 dot 12 which is really
very very very old. You should
really try to rereads the RFC

00:29:48.987,00:29:55.394
because on this new version
there are a lot of things
against smuggling like they said

00:29:55.394,00:30:00.399
you should try to avoid uh
chunked and cousintents. You
should really avoid re-writing

00:30:04.403,00:30:10.742
your own reverse proxy because
it's a very hard stuff but in
case of if one day you try to

00:30:10.742,00:30:16.815
write a reverse proxy the goal
of the reverse proxy is to
re-write all errors in a very

00:30:16.815,00:30:21.820
clean way. Do not take blindly
their theirs eyesight and give
it to a backend. Uh you should

00:30:25.023,00:30:30.028
try to read books on TCP IP
circuit connection because it
looks like something like an

00:30:32.130,00:30:37.135
obstruction which is simple but
infact it's really not simple.
You should also think about

00:30:39.905,00:30:44.910
browser and browser do not makes
HTTP errors uh a lot of HTTP
server is to allowing a lot of

00:30:48.413,00:30:53.418
things like HTTP 0 dot 9 because
of um monitoring tools which is
0 dot 9 or because of bugs or

00:30:56.655,00:31:01.593
because of bad implementation on
the right but I think you should
reject bad im-implementation and

00:31:04.296,00:31:09.301
you should retreat uh uh what
you allow in HTTP. You should be
interwound and this is one of

00:31:12.404,00:31:18.844
the problem. There is this
sentence uh which was in general
and implementation should be

00:31:18.844,00:31:23.849
conservative in it's sending
behavior and liberal in its
reasoning behavior but maybe

00:31:26.017,00:31:32.023
it's wrong maybe the the right
thing is not lib it's not being
liberal it's being robust like

00:31:32.023,00:31:38.930
you should think that you may
get some bad things and you
shouldn't think like maybe you

00:31:38.930,00:31:43.935
need uh a special error message
maybe but do not fix the things
bli-blindly and there's a new

00:31:47.973,00:31:54.045
RFC uh which is called draft
thomson postel was wrong which
is talking about this thing. We

00:31:54.045,00:31:59.050
should now be entrailed on the
the protocol [mic boom] edition.
I think it's so also that you

00:32:01.086,00:32:07.092
should be able to get more
option on on the HTTP server
configuration like you should

00:32:07.092,00:32:12.097
say I do not want to support
HTTP 0 dot 9 because even today
you may get an HTTP 2 server uh

00:32:17.302,00:32:24.176
in go for reasonable uh you've
got very nice HTTP 2 server but
there's still the HTTP 0 dot 9

00:32:24.176,00:32:29.181
support inside and you should
also be able to get the keep
alive thing without the

00:32:31.316,00:32:36.321
pipelining so there's no option
to say there's no pipelining on
this server. You could also try

00:32:41.293,00:32:46.298
to get back to HTTP 1 dot 0 but
you'd get some problems of
performance. Um you may also

00:32:51.937,00:32:56.942
think I was thinking things that
I think a reverse proxy will
secure your installation and

00:32:59.211,00:33:06.151
maybe infact it's the country.
Every time you add whatever
layer maybe you add another

00:33:06.151,00:33:11.156
issue. The reverse proxy trusts
the backend response and it's
the way it works and we never

00:33:14.192,00:33:19.231
think it works this way it means
you've got the reverse proxy and
you've got the back end PHP

00:33:19.231,00:33:24.236
application and you let everyone
write PHP application. Everyone
can break your reverse proxy

00:33:28.807,00:33:33.812
simply by sending several
response several responses so
the reverse proxy will always

00:33:37.749,00:33:42.754
trust the things from the back
end and we do not think the this
is the case. Um think about

00:33:47.292,00:33:53.365
things like Haproxy uh because
it's a very good tool to to
remove everything which is

00:33:53.365,00:33:59.604
strange. Nginx links has a
reverse proxy which is also
quite nice uh the next Apache

00:33:59.604,00:34:04.542
mod proxy will have the strict
protocol option which is nice.
Is HTTPS protection no it's just

00:34:08.213,00:34:13.218
uh a layer so it's not your full
protection because inside after
the SSL thing you've got just

00:34:16.321,00:34:21.326
HTTP 1 dot 1 and and maybe when
you add an SS Terminator you
just added one and never uh HTTP

00:34:24.629,00:34:29.634
server but HTTPS is great of
course. Is HTTP 2 protection yes
of course it's better against

00:34:33.405,00:34:38.410
smuggling but you can always ask
HTTP 1 dot 1 for an HTTP 2
server. It's just another

00:34:42.280,00:34:47.285
transport layer. Just the last
thing I wanted to reach is
called HTTP Wookiee uh it's an

00:34:54.092,00:34:59.097
open open source tool. I will
we'll use it uh today or maybe
tomorrow uh nuh- with uh test.

00:35:04.736,00:35:09.741
The goal of this thing is to
test uh reverse proxy
implementations and to fuzz HTTP

00:35:12.210,00:35:17.215
um I need to remove some of the
tests which are not fixed yet
everywhere but uh if you need to

00:35:20.118,00:35:25.123
fuzz your own server you could
use this tool. Uh if you got any
question I will be outside. Um

00:35:30.295,00:35:35.300
and that's it and thanks for for
everyone. [applause]