Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Servo should only support HTTPS connections, zero without "S" #20120

Closed
redox-questions opened this issue Feb 25, 2018 · 2 comments · Fixed by #25404
Closed

Servo should only support HTTPS connections, zero without "S" #20120

redox-questions opened this issue Feb 25, 2018 · 2 comments · Fixed by #25404
Labels
A-network

Comments

@redox-questions
Copy link

redox-questions commented Feb 25, 2018 •
edited

Hello,

first, this looks like a great future project, next-gen webbrowser, wow.

Second, I think it should only support HTTPS connections and not plain HTTP.

If it points to the future.

only problem: OCSP uses plain HTTP: https://moxie.org/papers/ocsp-attack.pdf
@jdm jdm added the A-network label Feb 25, 2018
@Darkspirit
Copy link
Sponsor Contributor

Darkspirit commented Mar 1, 2018 •
edited

Second, I think it should only support HTTPS connections and not plain HTTP.

  • Some (many?) operating systems are capable of presenting captive portal logins.
  • At least the location bar should default to https:// and mixed content should be strictly forbidden (maybe anything should be upgraded to https://, but that would promote webdev slovenliness).
  • Think of TOR's .onion domains, wifi router interfaces, (or Redox OS showing a captive portal login?).

only problem: OCSP uses plain HTTP

Revocation is broken. Firefox for Android only fetches OCSP for EV certs (if there was no stapled OCSP response).
The CAB Forum should enforce OCSP Must-Staple for EV certs.
Servo could omit any http:// OCSP/CRL fetching then. That would be cool. :)

@jdm
Copy link
Member

jdm commented Mar 25, 2018

I don't think cutting off access to non-HTTPS is feasible yet, given the huge volume of unsecured legacy web content.

@jdm jdm closed this as completed Mar 25, 2018
@Darkspirit Darkspirit mentioned this issue Dec 24, 2019
Closed
@Darkspirit Darkspirit mentioned this issue Jan 8, 2020
Merged
4 tasks
bors-servo pushed a commit that referenced this issue Jan 8, 2020
Auto merge of #25404 - Darkspirit:hsts, r=asajeffrey
080e66f 
Fix HSTS

The headers crate does not [expose](https://github.com/hyperium/headers/blob/0c42ad8cf56f9af28973c3da71616fa478781fdf/src/common/strict_transport_security.rs#L42) HSTS struct fields. At the moment, it's only usable for HSTS header encoding. An update of the headers crate would require a huge update of http, hyper, hyper_serde, net::decoder as well. Therefore I've copied the `typed_get::<StrictTransportSecurity>` decoding feature  for now, but with exposed struct fields. Let's remove this custom struct with the next hyper upgrade. I tried to prevent needless HSTS database lookups when network.enforce_tls.enabled is set.

---
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] These changes fix #14363, fix #20120.

- [x] There are tests for these changes
bors-servo pushed a commit that referenced this issue Jan 8, 2020
Auto merge of #25404 - Darkspirit:hsts, r=asajeffrey
2a61745 
Fix HSTS

The headers crate does not [expose](https://github.com/hyperium/headers/blob/0c42ad8cf56f9af28973c3da71616fa478781fdf/src/common/strict_transport_security.rs#L42) HSTS struct fields. At the moment, it's only usable for HSTS header encoding. An update of the headers crate would require a huge update of http, hyper, hyper_serde, net::decoder as well. Therefore I've copied the `typed_get::<StrictTransportSecurity>` decoding feature  for now, but with exposed struct fields. Let's remove this custom struct with the next hyper upgrade. I tried to prevent needless HSTS database lookups when network.enforce_tls.enabled is set.

---
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] These changes fix #14363, fix #20120.

- [x] There are tests for these changes
bors-servo pushed a commit that referenced this issue Jan 8, 2020
Auto merge of #25404 - Darkspirit:hsts, r=asajeffrey
e201b16 
Fix HSTS

The headers crate does not [expose](https://github.com/hyperium/headers/blob/0c42ad8cf56f9af28973c3da71616fa478781fdf/src/common/strict_transport_security.rs#L42) HSTS struct fields. At the moment, it's only usable for HSTS header encoding. An update of the headers crate would require a huge update of http, hyper, hyper_serde, net::decoder as well. Therefore I've copied the `typed_get::<StrictTransportSecurity>` decoding feature  for now, but with exposed struct fields. Let's remove this custom struct with the next hyper upgrade. I tried to prevent needless HSTS database lookups when network.enforce_tls.enabled is set.

---
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] These changes fix #14363, fix #20120.

- [x] There are tests for these changes
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
A-network
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Fix HSTS Darkspirit/servo
4 participants
@jdm @Darkspirit @redox-questions and others