Google Cloud Identity Aware Proxy (App Engine) - Strange web browser behavior?

Question

I am seeing some strange behavior using App Engine with Identity Aware Proxy in Chrome (Desktop & Mobile) / Firefox (Desktop & Mobile) / Safari (Desktop) / curl (Desktop)

I launched a static-file site on App Engine using these settings

app.yaml:

runtime: python27
api_version: 1
threadsafe: true

handlers:
- url: /(.*)
  static_files: index.html
  upload: index.html
  secure: always

index.html:



Hello World!

I then used the cloud console to enable the Identity Aware Proxy.

As expected, I was asked to sign in using the google account needed to access the page. All good.

However, sometimes I can access the site from a browser without credentials, or even from curl, which I feel should definitely not be possible?

It takes a bunch of refreshes / retries, but once it is reproduced I can reliably get the index page without authentication using Chrome, Firefox, Opera, and curl.

Questions:

Am I doing something completely stupid? Is it expected behavior to sometimes be able to access the page even in incognito/private mode, or using curl?
I know there is a default 10 minute caching header on static files served by App Engine, how does that factor in?
How does curl get mixed up in all of this? AFAIK https can not be cached by anyone except the UA making the request (and internally on Google's end)? Is there a cache on my computer that all of these sources talk to that I am not aware of?
Is this a problem on my computer/phone (i.e. once the page is cached somehow all UAs on that device can see the page without authenticating)?
Is this a problem on Google's end?

For completeness, here's the output from curl -v

curl -v https://xxxxxxxxxxxx.appspot.com
* Rebuilt URL to: https://xxxxxxxxxxxx.appspot.com/
*   Trying 172.217.22.180...
* TCP_NODELAY set
* Connected to xxxxxxxxxxxx.appspot.com (172.217.22.180) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/cert.pem
  CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server accepted to use h2
* Server certificate:
*  subject: C=US; ST=California; L=Mountain View; O=Google Inc; CN=*.appspot.com
*  start date: Mar 28 14:17:04 2018 GMT
*  expire date: Jun 20 13:24:00 2018 GMT
*  subjectAltName: host "xxxxxxxxxxxx.appspot.com" matched cert's "*.appspot.com"
*  issuer: C=US; O=Google Trust Services; CN=Google Internet Authority G3
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x7ff81780a400)
> GET / HTTP/2
> Host: xxxxxxxxxxxx.appspot.com
> User-Agent: curl/7.54.0
> Accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
< HTTP/2 200
< date: Fri, 20 Apr 2018 17:43:10 GMT
< expires: Fri, 20 Apr 2018 17:53:10 GMT
< etag: "8wDEQg"
< x-cloud-trace-context: 8e9c1b6803383aac532d48d9f0ac5fc2
< content-type: text/html
< content-encoding: gzip
< server: Google Frontend
< cache-control: public, max-age=600
< content-length: 54
< age: 371
< alt-svc: hq=":443"; ma=2592000; quic=51303433; quic=51303432; quic=51303431; quic=51303339; quic=51303335,quic=":443"; ma=2592000; v="43,42,41,39,35"
<
���(�ͱ�I�O���
* Connection #0 to host xxxxxxxxxxxx.appspot.com left intact
I-.Q�ч�l�!����Z�_$%

The output above SHOULD show a 302 redirect to IAP's login page, but as previously stated - it does not always do that!

TL;DR Why can I access App Engine static pages protected by IAP on my computer from contexts that should not be allowed access?

Thanks!

Matthew Sachs · Accepted Answer

Ah, you've run into an interesting corner case! There's some documentation of this at https://cloud.google.com/iap/docs/concepts-best-practices -- TL;DR, App Engine does some caching for static_files that interacts poorly with IAP. That page has some instructions you can apply if you want to protect your static_files. --Matthew, Google IAP Engineering

Google Cloud Identity Aware Proxy (App Engine) - Strange web browser behavior?

Answers (1)

Related Questions