Support for HTTPS and other privacy technologies

[kseistrup]

With Let's Encrypt in public beta, I decided to put SFW on HTTPS: I have SFW running on localhost and use the Caddy webserver as a frontend to handle TLS certificates and proxying.

Having Caddy in the front of SFW works well on a http connection, but on a https connection several things seem to fail:

1. The browser lock icon doesn't go green, probably meaning that there are insecure elements on the page. Which are those?
2. In the lower right corner, the site icons keeps turning (on http they almost instantly come to a halt).
3. When clicking wiki links, e.g., links on the “How To Wiki” page, the pages turn up with a title only — there are no contents.

Is there anything I can do to remedy these issues, save for running SFW on an insecure connection?

[almereyda]

Did you already create a 301 redirect on :80 for the same domain which is
serving wiki on :443, too?

On 12 January 2016 at 12:56, Klaus Alexander Seistrup <
notifications@github.com> wrote:

With Let's Encrypt https://letsencryptorg/ in public beta, I decided to
put SFW on HTTPS: I have SFW running on localhost and use the Caddy
https://caddyservercom/ webserver as a frontend to handle TLS
certificates and proxying

Having Caddy in the front of SFW works well on a http connection, but on a
https connection several things seem to fail:

1 The browser lock icon doesn't go green, probably meaning that there are
insecure elements on the page Which are those?
2 In the lower right corner, the site icons keeps turning (on http they
almost instantly come to a halt)
3 When clicking wiki links, eg, links on the “How To Wiki” page, the pages
turn up with a title only — there are no contents

Is there anything I can do to remedy these issues, save for running SFW on
an insecure connection?

—
Reply to this email directly or view it on GitHub
#71.

[kseistrup]

Yes.

[paul90]

We briefly spoke about this at last weeks hangout...

This will be handled as part of #72

The problem is that many of the links within the client are hardwired to use http, rather than https. The only short term solution is to listen on both port 80 and 443.

[WardCunningham]

Much of our client-side codebase pushes against assumptions as to how modern websites work. We are constantly bumping into single origin limitations. I suspect the TLS conversion will present as many difficulties or more. In our conversation last week I think we agreed that it is time to get started working these problems.

A good start might be enumerating problems as you have done. Let's write them initially as comments to this one issue. If we write a separate github issue for each problem we will lose perspective and dissipate our energies.

One additional problem we will face is that the existing assumptions of how the network works have been layered over with convenience abstractions (think jQuery) such that we scatter single lines of network code all over the code we write. Our long-term interest in crypto-networks hasn't yet driven us to good network-facing abstractions but this TLS need could get the ball rolling.

[herbsmn]

has any progress been made on this issue?

[WardCunningham]

Yes, for example:

fedwiki/wiki-client#176
fedwiki/wiki-client#177

[herbsmn]

Thanks for the quick response and thanks for all the work ya'll are doing with this. Can't wait to install it!

[paul90]

Those wiki-client changes were a first step - those parts of the federation which are on servers that don't support https will continue to be unreachable.

Also, in those changes I kept loading the remote site's flag using http, which will continue to give a warning, but allows the distinction to be made between wiki that are down, flag fails to load and is canted over, and those that don't support https, flag is displayed but is canted over.

A next step will be to rewrite/refactor the client network code to make it a lot more intelligent about how it works. So, if the origin is https it only makes https requests, probably using the origin as a proxy where the remote server doesn't support https.

[herbsmn]

it isn't good in all use cases, but in a lot of ways Tor onion services are better than TLS / HTTPS. So, I put federated wiki on an onion service as a proof of concept. i haven't added any content yet, but will in the future. here's what's up right now: http://hnnxjs3bcdlgjly5.onion

I might change the domain to a vanity onion in the future, so that link might not always work. Everything seems to be working in Tor Browser except for there's a bug that doesn't allow certain glyphs/dingbats to work in the current version, but I filed a bug. Sorry if this is too off topic for this issue. Was just trying to say that other security options exist other than TLS. My next test is to see if I can run the site with both TLS and the onion and edit from either one.

[WardCunningham]

I would like to continue this conversation so that I might understand what you have done and how well it is working. I've refreshed my understanding of Tor by consulting the page on wikipedia.

What was required to "put federated wiki on an onion service"? I understand this to be similar to port forwarding through NAT where the wiki server need not be modified but where wiki must be configured to know its external address in order for all services to work correctly.

Have you "claimed" a wiki site that exists behind an onion service? Federated wiki expects each participant to have their own site which is protected from edits by other users by additional credentials of some form.

Federated wiki pages travel between sites and accumulate a trail of those site's domain names so that other pages on all of those sites become addressable by page title alone. Have you seen this mechanism work for domains within the Tor network?

Federated wiki works well on a private LAN where all parties can resolve local domain names. These pages are easily "forked" from the LAN onto public internet sites from a browser with access to both networks. Once forked, the now public page does carry the private names of other sites that have participated in the page's creation.

The wiki server's page store can be shared between private and public servers. I do this sometimes with rsync between sites. I also often run various server versions on the same host using the same page store and find this works as one would expect.

I wonder what sort of latency one sees when editing wiki pages over Tor? Each edit creates an action that will be displayed in the client side journal when the round trip completes. On slow links this delay is visible. On very slow links it could interfere with subsequent edits. I would expect trouble if turn around took seconds instead of hundreds of milliseconds.

I thank you for your continued interest in this project and your willingness to share your experience.

[herbsmn]

I'm running Debian Jessie on a VPS. I got federated wiki running in the normal way. I then mainly followed these instructions: https://yawnbox.com/static/New-Democracy-Now-Onion-site.html except I used nginx instead of apache. I feel like the instructions at the link are fairly straight forward, so I'm not going to repeat them here, but if you have any quesitons, please ask.

I just figured out how to claim the site after finding this helpful guide: http://fedwiki.andysylvester.com/view/welcome-visitors/view/journal-2017/view/new-user-setup

Just as a test, I decided to fork fed.wiki.org's How to Wiki page and Andy's New User Setup page to my site and then I made a few edits: http://hnnxjs3bcdlgjly5.onion/view/welcome-visitors/view/how-to-wiki/view/new-user-setup/fedwiki.andysylvester.com/new-user-setup

As you can see at the link, one is able to see the "Older" and "Newer" links at the top of my page.

I can also see and click on the "Newer" link at the top of the pages I forked and view my fork from their pages: http://fed.wiki.org/view/welcome-visitors/view/how-to-wiki/hnnxjs3bcdlgjly5.onion/how-to-wiki http://fedwiki.andysylvester.com/view/welcome-visitors/view/new-user-setup/hnnxjs3bcdlgjly5.onion/new-user-setup

I would say that using Tor is slowish, but not would not describe it as very slow. If you would like me to provide you with some logs to look into this more, please let me know.

[herbsmn]

The only thing that doesn't seem to be working right now is the fact that my favicon isn't showing up in the Tor Browser tabs. I can see everyone else's favicon on their site's browser tab though.

[WardCunningham]

I suspect favicon unnecessarily specifies a protocol of http and that is interfering with your setup. We have prototype code that constructs favicon links which will ultimately be sensitive to cross-protocol accesses and reroute requests through a proxy if need be. You can see that there are a half-dozen favicon references in the core javascript alone.

fedwiki/wiki-client@97e7861

[herbsmn]

Thanks for working on the favicon issue! I updated my federate wiki instance and it seems to be working perfectly now! Please let me know if you have any other questions about federated wiki on onion hidden services or Tor in general. One nice feature is that it hides where the server is located. The connection is also end to end encrypted from the user's browser to the server and back.

[herbsmn]

Just to clarify, Tor Onion Services used to be called Tor Hidden Services. The name was changed because it was thought that words like "Hidden" "Deep" and "Dark" have negative connotations. I agree that the change in name is wise. However, Tor's website still calls it hidden services on this page that describes how it works: https://www.torproject.org/docs/hidden-services.html.en