queue, worker, tools: Serve live.log over HTTPS from ec2 instance (Mixed Content Issues)

RESOLVED WONTFIX

Status

Taskcluster
General
RESOLVED WONTFIX
4 years ago
3 years ago

People

(Reporter: jonasfj, Unassigned)

Tracking

Details

(Reporter)

Description

4 years ago
I know serving from ec2 spot node with HTTPS sounds hard to do...
But maybe we can proxy requests or something... It would make me sad that queue should proxy long http streams with live logs.. Suggestions welcome.

In short, live.log causes mixed-content errors on tools.taskcluster.net.
This because we fetch live.log from ec2 directly and we don't have HTTPS on those nodes.

---
Note, tools.taskcluster.net MUST use HTTPS, we store credentials in localStorage.
So forcing the task-inspector to run HTTP is not really a good solution.
Going forward will probably have other tools that consume live.log, task-graph inspector already does this too.

Temporary hack, is to ignore the mix content errors and allow mixed content for tools.taskcluster.net in Firefox.
It's sad, because this is an AJAX request where, we are completely responsible for reading/validating the response.
(Reporter)

Comment 1

4 years ago
We should check if this can be fixed with with CSP headers:
https://developer.mozilla.org/en-US/docs/Web/Security/CSP

S3 can't serve these... but if we really have to we can either serve from heroku (which makes me feel stupid).
Or we can find another CDN to serve content from. Either way, it's worth testing if CSP will allow us to do mixed
content.

Thanks to :wchen for suggesting this...
(Reporter)

Comment 2

4 years ago
I've started a HTTPS proxy project...
https://github.com/taskcluster/taskcluster-https-proxy

Note:
There is two ways to authenticate:
 1. Request with an 'origin' that is allowed,
 2. Sign the request

We need to restrict who can use this proxy, because otherwise random people will start using it :)
I think it's of no use, if you must specify the `origin` header, because XHR always overwrites this.
My idea is that we'll have a few origins like tools.taskcluster.net that doesn't require authentication.

But if you make a custom deployment of taskcluster-tools (on HTTPS), then you'll need to have it added to list of allowed origins OR you can just request that people always authenticate.


Remark, this approach puts the burding of proxying HTTP requests into the user making requests over HTTPS.
A nice hack might be to build a proper HTTPS proxy and build it into taskcluster-tools. Then use something like the proxy-authentication header to authenticate against that.

Final note, we should probably still test if CSP could do the trick, I'm starting to doubt it.
(Reporter)

Comment 3

3 years ago
This is potentially implemented in bug 1132355 using a DNAME record... It's a bit interesting :)
(Reporter)

Comment 4

3 years ago
This will be fixed in bug 1132355.  We should give up on proxy ideas.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → WONTFIX
Component: TaskCluster → General
Product: Testing → Taskcluster
Target Milestone: --- → mozilla41
Version: unspecified → Trunk
Resetting Version and Target Milestone that accidentally got changed...
Target Milestone: mozilla41 → ---
Version: Trunk → unspecified
You need to log in before you can comment on or make changes to this bug.