Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

#13174 closed enhancement (fixed)

Amazon CloudFront sets X-Forwarded-For

Reported by: dcf Owned by: dcf
Priority: Medium Milestone:
Component: Obfuscation/meek Version:
Severity: Keywords:
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Amazon sets the X-Forwarded-For header that contains the client's true IP. Here's what the header looks like as it arrives at meek-server:

POST / HTTP/1.1
Host: d1727xplrgzao3.cloudfront.net
Via: 1.1 c54d7f08e2f3dab1918454910cc8aad0.cloudfront.net (CloudFront)
X-Amz-Cf-Id: 4ygWFdM8S5fIh-pnW7BK7hKsA7vv6tba-G30YwVHLCXT2Kblcl_yDw==
Connection: Keep-Alive
Content-Length: 244
Accept-Encoding: gzip, deflate
X-Forwarded-Proto: https
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Firefox/24.0
X-Forwarded-For: 192.0.2.101
CloudFront-Is-Mobile-Viewer: false
CloudFront-Is-Tablet-Viewer: false
CloudFront-Is-Desktop-Viewer: true
CloudFront-Viewer-Country: US
Accept-Language: en-US,en;q=0.5
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
CloudFront-Forwarded-Proto: https
X-Session-Id: FHY4jxw72uodLxdRbrFtqRMnBbMxoa5USSuLj1pzh4w=
Content-Type: application/octet-stream

From a censorship point of view, the presence of the client IP address doesn't make a difference, because the request is out of the censor's view by the time the IP is visible. From a surveillance point of view, it doesn't really increase the exposure of clients over ordinary bridges or other transports, because someone surveilling one of those bridges also gets a list of client IPs. But if we can hide the IP on the link between the CDN and meek-server, then we can be in an even better situation with respect to surveillance.

Previously we didn't enable HTTPS on the link between App Engine and meek-server because it increased latency. That was for App Engine, though, not Amazon, and HTTPS is not as slow anymore with optimizations made in newer Go releases. (Now it's about 300 ms with HTTPS and 100 ms without.)

Child Tickets

Change History (3)

comment:1 Changed 3 years ago by dcf

For comparison, here is what a header from App Engine looks like:

POST / HTTP/1.1
Content-Type: application/octet-stream
X-Session-Id: D/p+00g7vJA5ZP01r8It8exRl7LzDO3qkBMuxu1Cmkw=
User-Agent: AppEngine-Google; (+http://code.google.com/appengine; appid: s~meek-reflect)
Host: meek.bamsoftware.com:7002
Content-Length: 249
Accept-Encoding: gzip

comment:2 Changed 3 years ago by dcf

Resolution: fixed
Status: newclosed

I enabled HTTPS between CloudFront and meek-server. Let's see how it goes! I had some trouble with "502 Bad Gateway" errors until I changed the configuration not to forward the Host header—it was causing the SNI received at meek-server to be the cloudfront.net subdomain and the CloudFront client to hang up right after the TLS handshake. (Some time around June, CloudFront changed its behavior with respect to the Host header.) I updated the instructions at doc/meek#AmazonCloudFront to note the header issue.

As a side effect of not forwarding Host, the header got a little smaller. Note the absence of e.g. CloudFront-Is-Mobile-Viewer.

POST / HTTP/1.1
Host: meek.bamsoftware.com
Via: 1.1 c54d7f08e2f3dab1918454910cc8aad0.cloudfront.net (CloudFront)
X-Amz-Cf-Id: GEa3aeRPZsED7h4rdOm4mDlWawfqJq4_gWOAh4_IHQx7eWihDuj8MA==
Connection: Keep-Alive
Content-Length: 0
Accept-Encoding: gzip, deflate
X-Forwarded-Proto: https
User-Agent: Amazon CloudFront
X-Forwarded-For: 192.0.2.101
X-Session-Id: b+vY64oFn23X1x74/Iq24WhDOscVqsO+zgqpXwAebhw=

comment:3 Changed 3 years ago by dcf

Here's what you get from Azure (with a Python httplib connection).

POST / HTTP/1.1
Host: meek.bamsoftware.com:7002
Accept-Encoding: identity
Content-Length: 543
X-Session-Id: X4q+OZyfKilWku6VYvrgoYqDpWL9XUAwa2Ddc2FNAso=
Note: See TracTickets for help on using tickets.