Strange TLS interactions
Opened this issue · 8 comments
Just a heads up in case anybody else is running into similar issues:
Using config /home/alex/.config/.vf1rc
Welcome to VF-1!
Enjoy your flight through Gopherspace...
VF-1> tls
Battloid mode engaged! Only accepting encrypted connections.
VF-1> bm
[1] Alex Schroeder [TLS]/
...
VF-1> 1
Welcome to the Gopher version of this wiki.
...
VF-1> b
[1] Alex Schroeder [TLS]/
...
[4] Moku Pona Updates/
...
VF-1> 4
ERROR: [SSL: WRONG_VERSION_NUMBER] wrong version number (_ssl.c:1056)
gophers://alexschroeder.ch:70/1map/Moku_Pona_Updates is probably not encrypted.
Use 'tls' to disable encryption.
VF-1> tls
Battloid mode disengaged! Switching to unencrypted channels.
VF-1> 4
Enabling battloid mode to connect to encrypted server.
ERROR: [SSL: WRONG_VERSION_NUMBER] wrong version number (_ssl.c:1056)
gophers://alexschroeder.ch:70/1map/Moku_Pona_Updates is probably not encrypted.
Use 'tls' to disable encryption.
The problem is that item 4 is for a non-encrypted link and yet VF-1 thinks it goes to an encrypted site, perhaps because I mistakenly tried to visit it with TLS just before that.
Or in a different session, same bookmark file:
VF-1> b
[1] Alex Schroeder [TLS]/
...
VF-1> 1
^C
VF-1> tls
Battloid mode engaged! Only accepting encrypted connections.
VF-1> 1
Cannot enter demilitarized zone in battloid!
Use 'tls' to disable battloid mode before leaving encrypted gopherspace.
Here, VF-1 is again confused, thinking that the link goes to an unencrypted site, perhaps because I tried to visit it just before that without TLS but cancelled it (i.e. again an error).
I'm suspecting that we use gopheritem_from_line which creates gopher items based on the current TLS mode. But this is wrong because we can never know the TLS requirements of a destination based on out current state. This wasn't a problem in the past, because we didn't check whether gi.tls and self.tls matched up. But if we do check, then we need something else. I'm thinking of something like #63 but I'm not sure that this is all we need.
I think at least part of this issue is bookmark specific. VF-1 stores its bookmarks in the gopher menu format, and there's just no way to specify TLS-or-not-ittude in that file, so bookmarking an encrypted location is never going to work. It would be nice to fix this, and I think the only way to do it without changing the bookmark file (and I like that it's a gopher menu, makes all the sense in the world) would be to add support for the ugly h item type URL: hack to store a gophers:// URL.
I agree that gopheritem_from_line setting the .tls attribute based on current Battloid mode status makes no sense. If nothing else, if the port is 70, TLS should always be set off, IMHO. We don't want to encourage people running encrypted gopher on the standard gopher port. I have some uncommitted code that I'm testing where, if a menu is downloaded over TLS, then any items in that menu with the same hostname and port as the menu itself have .tls set to True. My hope is that will at least give us sensible behaviour within a single encrypted server's space.
Okay, I've used the h-type URL: hack to make TLS bookmarks work correctly. The above-discussed logic for setting .tls got pushed in too because it was too hard to disentangle them. I'm happy to change that part if we think of something better.
OK, so here's a link from my bookmark file, with ⭾ used instead of a tabulator.
1Alex Schroeder [TLS]⭾⭾alexschroeder.ch⭾7443
I have more than one problem.
The first link is my old bookmark, which still doesn't work. I continue to think that this is a problem because I open VF-1, use the tls command, and visit the menu item, which looks correct to me, but VF-1 gives me an error.
Welcome to VF-1!
Enjoy your flight through Gopherspace...
VF-1> bm
[1] Alex Schroeder [TLS]/
...
VF-1> tls
Battloid mode engaged! Only accepting encrypted connections.
VF-1> 1
Cannot enter demilitarized zone in battloid!
Use 'tls' to disable battloid mode before leaving encrypted gopherspace.
Here's an additional example:
VF-1> go alexschroeder.ch/1Gopher/menu
...
[8] via TLS/
...
VF-1> tls
Battloid mode engaged! Only accepting encrypted connections.
VF-1> 8
Cannot enter demilitarized zone in battloid!
Use 'tls' to disable battloid mode before leaving encrypted gopherspace.
OK, trying it the other way:
VF-1> tls
Battloid mode disengaged! Switching to unencrypted channels.
VF-1> 8
ERROR: Connection refused!
No matter what I do, I can't follow this link.
If I understand your change correctly, all the links to TLS encrypted sites must now use the h type?
There's an unrelated problem with the h type and my bookmarks, I think:
hAlex Schroeder [encrypted]⭾URL:gophers://alexschroeder.ch:7443/1⭾alexschroeder.ch⭾7443
This doesn't display correctly: the name "Alex Schroeder [encrypted]" is not used.
[9] gophers://alexschroeder.ch:7443/1/
But it works. :)
VF-1> 9
Enabling battloid mode to connect to encrypted server.
As I was playing around with the add command I also noticed that I could add a bookmark to the bookmark file. Here, it worked fine, with or without TLS:
1bookmarks⭾/home/alex/.vf1-bookmarks.txt⭾⭾None
But here's where I run into the error I mentioned above and then add a bookmark file:
Welcome to VF-1!
Enjoy your flight through Gopherspace...
VF-1> tls
Battloid mode engaged! Only accepting encrypted connections.
VF-1> bm
[1] Alex Schroeder [TLS]/
...
VF-1> 1
Cannot enter demilitarized zone in battloid!
Use 'tls' to disable battloid mode before leaving encrypted gopherspace.
VF-1> add test
Due to the previous error, both VF-1 and I are now confused. The last add command still bookmarks the bookmark file, but thinks it's an URL.
htest⭾URL:/home/alex/.vf1-bookmarks.txt⭾⭾None
I'm hoping to release 1.0.0 soon and so I want to get this TLS behaviour sorted out. Right now the TLS logic has become somewhat ad hoc and kludgey, and still doesn't "just work".
One possibility is that we roll things back to the old approach, where a user manually toggles between "TLS on" mode, where each and every request is over TLS no matter what, and "TLS off" mode, where no request is ever over TLS. This offers a pretty horrible use experience (for the 0.1% of users trying to do TLS stuff in the first place), but has the advantage that we can quickly, easily and correctly document the TLS behaviour and it's very easy for users to understand what to expect and when.
The other possibility is that we come up with a nice, clean, consistent approach to offering user-friendly TLS and refactor the current mess to implement that approach.
Or we can do the first thing for 1.0.0 and make the second thing the goal for 1.1.0.
What are your feelings on this matter, and how much time and energy to you have to spare on this matter in the coming, say, 7 days or so?
In the coming 7 days: zero time to spare, sadly. I think going back to explicit TLS mode works for me: it's like having two binaries: one is a traditional gopher client, the other a secure gopher client. And you you can switch modes without restart. Beautiful! Haha, it's all a matter of perspective. Easy code to read, easy code to document, easy to explain even if clunky to use... I think these are three good reasons to keep it as simple as possible.
No worries! I will roll things back to the old explicit TLS mode for 1.0.0. Enjoy your trip!