Index

Civil Society And Community
Freedom Of Information
Hosting
Market

Civil Society And Community

Privacy International

link: https://privacyintyqcroe.onion/
plain: https://privacyintyqcroe.onion/
proof: see tls/ssl certificate
check:

Riseup Home

link: http://vww6ybal4bd7szmgncyruucpgfkqahzddi37ktceo3ah7ngmcopnpyyd.onion/
plain: http://vww6ybal4bd7szmgncyruucpgfkqahzddi37ktceo3ah7ngmcopnpyyd.onion/
proof: link
check:

Riseup Onion Index

provides shared notepad, file sharing, code hosting, and other services

link: http://vww6ybal4bd7szmgncyruucpgfkqahzddi37ktceo3ah7ngmcopnpyyd.onion/en/security/network-security/tor#riseups-tor-onion-services
plain: http://vww6ybal4bd7szmgncyruucpgfkqahzddi37ktceo3ah7ngmcopnpyyd.onion/en/security/network-security/tor#riseups-tor-onion-services
proof: link
check:

Freedom Of Information

DanWin

link: https://danwin1210.me
plain: https://danwin1210.me
proof: see tls/ssl certificate
check:

Freedom of Information

link: http://5pxgor7yuvsjafwr.onion/
plain: http://5pxgor7yuvsjafwr.onion/
proof: see tls/ssl certificate
check:

Rumi Books

eBooks, Documents, Magazines

link: http://rumibookzo4fkho4.onion/
plain: http://rumibookzo4fkho4.onion/
proof: see tls/ssl certificate
check:

The Anarchist Library

Archive of Books

link: https://theanarchistlibrary.org/category/topic
plain: https://theanarchistlibrary.org/category/topic
proof: see tls/ssl certificate
check:

Hosting

Freedom Hosting

link: http://fhostingineiwjg6cppciac2bemu42nwsupvvisihnczinok362qfrqd.onion/
plain: http://fhostingineiwjg6cppciac2bemu42nwsupvvisihnczinok362qfrqd.onion/
proof: see tls/ssl certificate
check:

Market

Digital Thrift Shop

link: http://kw4zlnfhxje7top26u57iosg55i7dzuljjcyswo2clgc3mdliviswwyd.onion
plain: http://kw4zlnfhxje7top26u57iosg55i7dzuljjcyswo2clgc3mdliviswwyd.onion
proof: see tls/ssl certificate
check:

Flaky Sites

These sites have apparently stopped responding.

Footnotes

This file (README.md) is auto-generated
- Do NOT submit changes NOR pull-requests for it
- Please submit an Issue for consideration / change requests
If both v2 and v3 addresses are provided for a service, the v3 address will be preferred / cited
At the moment where an organisation runs 2+ onion addresses for closely related services that do not reflect distinct languages / national interests, I am posting a link to an index of their onions. Examples: Riseup, Systemli, TorProject, …
The master list of Onion SSL EV Certificates may be viewed at https://crt.sh/?q=%25.onion

RWOS Status Detector

site up
site up, and redirected to another page
site up, but could not access the page
site up, but reported a system error
site returned no data, or is down, or curl experienced a transient network error
site is newly added, no data yet

Codes & Exit Statuses

Mouse-over the icons for details of HTTP codes, curl exit statuses, and the number of attempts made on each site.

codes are from HTTP and are documented elsewhere; RWOS-internal ones include:
- 901, 902, 903 - malformed HTTP response
- 904 - HTTP status code parse error
- 910 - connection timeout
exits are from Curl and are documented elsewhere; common ones include:
- 7 - “curl couldn’t connect”
- 52 - “curl got nothing”, received no data from upstream

TLS Security

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 requests in ways that are fundamentally different to HTTP, e.g.:

with respect to cookie handling, or
where the trusted connection terminates, or
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 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.

semi-secure HTTP Onion site, protected by Onion circuits at best; will not respect browser secure/HTTPS behaviour
secure HTTPS Onion site, protected by both Onion circuits and TLS, will respect browser secure/HTTPS behaviour

Source Code

author : lecmuffett