commit: nits2

This commit is contained in:
Alec Muffett 2019-12-05 16:44:14 +00:00
parent 383f42212d
commit 38cb477491
2 changed files with 16 additions and 6 deletions

View File

@ -44,12 +44,12 @@ Mouse-over the icons for details of HTTP codes, curl exit statuses, and the numb
Due to the fundamental protocol differences between `HTTP` and
`HTTPS`, it is not wise to consider HTTP-over-Onion to be "as secure
as HTTPS"; web browsers *do* and *must* treat HTTPS in ways that are
fundamentally more secure than HTTP, e.g.:
as HTTPS"; web browsers **do** and **must** treat HTTPS in ways that
are fundamentally more secure than HTTP, e.g.:
- with respect to cookie handling, or
- where the trusted connection terminates, or
- how to deal with loading embedded insecure content
- how to deal with loading embedded insecure content, or
- whether to permit access to camera and microphone devices (WebRTC)
...and the necessity of broad adherence to web standards would make it
@ -57,6 +57,11 @@ harmful to attempt to optimise just one browser (e.g. Tor Browser) to
elevate HTTP-over-Onion to the same levels of trust as HTTPS-over-TCP,
let alone HTTPS-over-Onion.
Doubtless some browsers will *attempt* to implement
"better-than-default trust and security via HTTP over onions", but
this behaviour will not be standard, cannot be relied upon by
clients/users, and will therefore be **risky**.
**tl;dr** - HTTP-over-Onion should not be considered as secure as
HTTPS-over-Onion, and attempting to force it thusly will create a
future compatibility mess for the ecosystem of onion-capable browsers.

View File

@ -44,12 +44,12 @@ Mouse-over the icons for details of HTTP codes, curl exit statuses, and the numb
Due to the fundamental protocol differences between `HTTP` and
`HTTPS`, it is not wise to consider HTTP-over-Onion to be "as secure
as HTTPS"; web browsers *do* and *must* treat HTTPS in ways that are
fundamentally more secure than HTTP, e.g.:
as HTTPS"; web browsers **do** and **must** treat HTTPS in ways that
are fundamentally more secure than HTTP, e.g.:
- with respect to cookie handling, or
- where the trusted connection terminates, or
- how to deal with loading embedded insecure content
- how to deal with loading embedded insecure content, or
- whether to permit access to camera and microphone devices (WebRTC)
...and the necessity of broad adherence to web standards would make it
@ -57,6 +57,11 @@ harmful to attempt to optimise just one browser (e.g. Tor Browser) to
elevate HTTP-over-Onion to the same levels of trust as HTTPS-over-TCP,
let alone HTTPS-over-Onion.
Doubtless some browsers will *attempt* to implement
"better-than-default trust and security via HTTP over onions", but
this behaviour will not be standard, cannot be relied upon by
clients/users, and will therefore be **risky**.
**tl;dr** - HTTP-over-Onion should not be considered as secure as
HTTPS-over-Onion, and attempting to force it thusly will create a
future compatibility mess for the ecosystem of onion-capable browsers.