[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [gopher] Tor for Gopher

On 2/13/2017 9:47 PM, Christoph Lohmann wrote:
Greetings comrades.

This ugly discussion of how to add TLS to gopher has lead to all kind of
extension proposals which look so ugly  I  wouldn’t  want  to  implement
them.  The CA system is broken and will not lead to any security. Do you
really trust Let’s Encrypt, when they issue certificates for everyone? I

Not to go off topic on you Christoph, but separate to the issue of why you started this discussion, *yes*, I *do* trust LE... and I'll tell you why.

SSL (TLS) has NEVER been about doing business with or even being able to verify that you are communicating with *who* you presume to be communicating with at the end point. There have been all sorts of schemes to charge people more and more money just to have kewl looking real estate take up additional space in the address bar of a browser for the sake of the exclusive right to pay more money for such a nonsensical graphic in a browser or some stupid seal on a site that says you paid a bunch of money to ensure that traffic and communications between your site is secured with *some* level of encryption.

That having been said, SSL, for lack of a better term, ensures *only* that there is an encrypted session between you, the user running the browser, and the site that you have connected with, thereby providing some measure of confidence that there's not some MitM sniffing out your banking password or snatching up your cookies with Firesheep so that goombah sitting over there in the corner of the coffee house can post embarrassing things to your friends on faceplant that seemingly were from you.

The notion that verisign, thawte, geotrust, or any of the other players out there can actually verify that the cert was even issued to the party to whom is listed on the cert is total bullshit - I've created lots of certs for customers in the past and myself too and then guffawed myself right out of my chair because I realized that I circumvented their verification processes by virtue of having to have a cert ready and in place before the start of business for my client on the following day, without being afforded the luxury of having my client do their due dilligence in setting up for the verification process themselves.

Therefore, whereas, heretofor, and other lawyerisms aside...

1.) SSL verifies that you have an encrypted connection with a website (which may have been compromised anyway, already).

2.) SSL never has fully been able to guarantee that the cert was issued to the party to whom is listed on the cert.

3.) SSL has at several points in the past been compromised, most recently by virtue of issues in OpenSSL, that left huge holes in the security of cPanel and Plesk managed hosting instances because CentOS didn't push, or the hosting provider didn't push, the patches to shore up those holes.

SSL ensures that you have an encrypted connection, and I am a proponent of the notion that all HTTP traffic should take advantage of this, especially in light of the fact that search engines now routinely index secure content, and SNI is the way of the name based virtual hosting in the connnectionless oriented browsing environment.

If everyone would just once and for all realize that SSL never has verified that you are talking to who the cert says you're talking to, and only that you are talking to an end point via and encrypted session, there would be much less hype over whether everyone should be able to have encrypted communications for free.

You might be of a different opinion - you might believe that the *who* can be guaranteed, but it cannot. The only thing that can be guaranteed is that the conversation is encrypted, and that being enough to safeguard most communications, it should be free and LE is doing a fine job of breaking the backs of those who have exploited and defrauded the public for waaaaayyyy too long (i.e., verisign).

So would it be better to just use self-signed certs? But of course it would, because the expectation of identity would be obviously not be part of the secure nature of the connection, but we're talking about a public that just doesn't get it, so you need someone like LE to give them some semblance of confidence that the crooks at the bank have been gouging the consumer for over the last couple of decades.

Gawd when I get on that soapbox! No offense Christoph, I'm just diatribing out on what you already know to be the case technically, although you may have a different opinion than mine philosophically, although I know you to be a bit of a paranoid so I was surprised at your exclamation lolz.

I've never been a fan of anonymity either, although that's a different matter and my patience has been duly tested with all of the farming implements used by assholes like faceplant and google and other big (and not so big) data miners.

Kindest regards,


That  is the reason why I am proposing a simpler migration strategy: Let
us move all gopherholes to tor. Running a  hidden  service  requires  no
modification except for changing the internal links to the onion domain.
I do that at bitreich.org[0][1] by having a hidden service  pointing  to
port  70  but  the  redirect in the configuration is to a different port
which has geomyidae running with the argument ‐h hg6vgqziawt5s4dj.onion.
All menu entries in gph files pointing to »server« will be replaced with
that and you are kept in the tor network.

For clients it is simply: torify lynx gopher://hg6vgqziawt5s4dj.onion

I have started collecting onion gopherholes [2].

What  we  get: Security (hash in onion domain), anonymity (tor network),
moral superiority by supporting tor and their efforts


Christoph Lohmann

[0] gopher://bitreich.org
[1] gopher://hg6vgqziawt5s4dj.onion
[2] gopher://hg6vgqziawt5s4dj.onion/1/lawn/onion

Gopher-Project mailing list

This email has been checked for viruses by Avast antivirus software.

Gopher-Project mailing list

Reply to: