Git-Mirrors/real-world-onion-sites
1
0
Fork 0
mirror of https://github.com/alecmuffett/real-world-onion-sites.git synced 2024-10-01 01:06:18 -04:00
Code Issues Packages Projects Releases Wiki Activity

commit: editorialising

Browse Source
This commit is contained in:
Alec Muffett 2019-12-05 16:15:10 +00:00
parent 4a34c9d261
commit 86316da870
2 changed files with 42 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

21
01-preamble.md
View File

@ -39,3 +39,24 @@ Mouse-over the icons for details of HTTP codes, curl exit statuses, and the numb
- exits [are from Curl and are documented elsewhere](https://curl.haxx.se/libcurl/c/libcurl-errors.html); common ones include:
- `7` - "curl couldn't connect"
- `52` - "curl got nothing", received no data from upstream
### TLS Security
- :wrench: semi-secure HTTP Onion site, protected by Onion circuits at
best; will not respect browser secure/HTTPS behaviour
- :closed_lock_with_key: secure HTTPS Onion site, protected by both
Onion circuits and TLS, will respect browser secure/HTTPS behaviour
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.: with respect to cookie
handling or loading insecure content - and the necessity of broad
adherence to web standards would make it harmful to attempt to
optimise just one browser (Tor Browser) to elevate HTTP-over-Onion to
the same levels of trust as HTTPS-over-TCP, let alone
HTTPS-over-Onion.
tl;dr - HTTP-over-Onion is not as secure as HTTPS-over-Onion, and
attempting to force it to be so will create a compatibility mess for
the ecosystem of onion-capable browsers.

21
README.md
View File

@ -40,6 +40,27 @@ Mouse-over the icons for details of HTTP codes, curl exit statuses, and the numb
- `7` - "curl couldn't connect"
- `52` - "curl got nothing", received no data from upstream
### TLS Security
- :wrench: semi-secure HTTP Onion site, protected by Onion circuits at
best; will not respect browser secure/HTTPS behaviour
- :closed_lock_with_key: secure HTTPS Onion site, protected by both
Onion circuits and TLS, will respect browser secure/HTTPS behaviour
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.: with respect to cookie
handling or loading insecure content - and the necessity of broad
adherence to web standards would make it harmful to attempt to
optimise just one browser (Tor Browser) to elevate HTTP-over-Onion to
the same levels of trust as HTTPS-over-TCP, let alone
HTTPS-over-Onion.
tl;dr - HTTP-over-Onion is not as secure as HTTPS-over-Onion, and
attempting to force it to be so will create a compatibility mess for
the ecosystem of onion-capable browsers.
----
# Index