tlsdate and hidden service websites

[HulaHoopWhonix]

We are experimenting with using hidden service websites as time sources (SecureDrop instances listed: https://freedom.press/securedrop/directory) for tlsdate. This takes eliminates the need for cert-pinning and SSL CA MITM entirely because it relies on Tor's authentication.

At the moment this doesn't seem possible, I think the reason is tlsdate still expects the destination to be HTTPS explicitly while all HSs rely on Tor for their secure connections and present themselves as HTTP. Can you please adjust tlsdate to drop the tls requirement if its set to use a proxy (Tor), or, make tls use optional?

The error that I get:
SSL connection failed
child process failed in SSL handshake

To test use:

tlsdate -w -V -n -H [hiddenservice.onion]

[HulaHoopWhonix]

sudo tlsdate -w -V -n dtsxnd3ykn32ywv6.onion

This works. Should have played around more with it before opening this ticket.

[HulaHoopWhonix]

After the discussion here https://github.com/Whonix/Whonix/issues/351
I found out it doesn't actually work.

Jacob can you please comment on how or what is needed to use tlsdate for this?

[HulaHoopWhonix]

Full verbose report:

user@host:~$ sudo tlsdate --verbose --verbose -w -V -n -H dtsxnd3ykn32ywv6.onion
V: tlsdate version 0.0.8
V: We were called with the following arguments:
V: validate SSL certificates host = dtsxnd3ykn32ywv6.onion:443
V: RECENT_COMPILE_DATE is 1410720289.000000
V: we'll do the time warp another time - we're not setting clock
V: attemping to drop administrator privileges
V: time is currently 1413238768.908927128
V: time is greater than RECENT_COMPILE_DATE
V: using TLSv1_client_method()
V: Using OpenSSL for SSL
V: opening socket to dtsxnd3ykn32ywv6.onion:443
SSL connection failed
child process failed in SSL handshake

[ioerror]

What happens when you set a proxy explicitly?

[adrelanos]

(Tested on a plain Debian wheezy system using system Tor deb package from official Debian wheezy apt repository.)

Testing first with curl, to show that both the hidden service and the Tor proxy is functional.

curl --head --socks5-hostname 127.0.0.1:9050 dtsxnd3ykn32ywv6.onion ; echo $?

HTTP/1.1 200 OK
Date: Tue, 14 Oct 2014 14:37:08 GMT
Server: Apache/2.2.22 (Debian)
Cache-Control: no-cache, no-store, must-revalidate
Pragma: no-cache
Expires: -1
Vary: Accept-Encoding
Content-Type: text/html; charset=utf-8

0

Now trying with tlsdate and explicit proxy settings.

tlsdate --verbose --verbose --skip-verification --http --showtime=human --dont-set-clock -x socks5://127.0.0.1:9050 -H dtsxnd3ykn32ywv6.onion -p 80

V: tlsdate version 0.0.7
V: We were called with the following arguments:
V: disable SSL certificate check host = dtsxnd3ykn32ywv6.onion:80
WARNING: Skipping certificate verification!
V: RECENT_COMPILE_DATE is 1408958107.000000
V: we'll do the time warp another time - we're not setting clock
V: attemping to drop administrator privileges
V: time is currently 1413297394.52468787
V: time is greater than RECENT_COMPILE_DATE
V: using TLSv1_client_method()
V: Using OpenSSL for SSL
V: opening socket to 127.0.0.1:9050
V: proxy5: connecting dtsxnd3ykn32ywv6.onion:80
V: proxy5: connected
SSL connection failed
child process failed in SSL handshake

[HulaHoopWhonix]

Same message unfortunately:

user@host:~$ sudo tlsdate --verbose --verbose -w -V -n -H -x socks5://10.152.152.10:9050 dtsxnd3ykn32ywv6.onion
V: tlsdate version 0.0.8
V: We were called with the following arguments:
V: validate SSL certificates host = -x:443
V: RECENT_COMPILE_DATE is 1410720289.000000
V: we'll do the time warp another time - we're not setting clock
V: attemping to drop administrator privileges
V: time is currently 1413241210.849379327
V: time is greater than RECENT_COMPILE_DATE
V: using TLSv1_client_method()
V: Using OpenSSL for SSL
V: opening socket to -x:443
SSL connection failed
child process failed in SSL handshake

Its just a guess here but maybe if tlsdate has an "onion" flag -o enabled, it should not attempt to initiate an ssl connection?

That's better than trying to guess if a user is using .onion urls or that the proxy they are running is Tor.

[HulaHoopWhonix]

N.B. The address for the socksport I used is for Whonix Gateway - not localhost.

[HulaHoopWhonix]

I tried a slightly different command to double check and I get the same result.

user@host:~$ tlsdate --verbose --verbose --skip-verification --http --showtime=human --dont-set-clock -x socks5://10.152.152.10:9050 -H dtsxnd3ykn32ywv6.onion -p 80
V: tlsdate version 0.0.8
V: We were called with the following arguments:
V: disable SSL certificate check host = dtsxnd3ykn32ywv6.onion:80
WARNING: Skipping certificate verification!
V: RECENT_COMPILE_DATE is 1410720289.000000
V: we'll do the time warp another time - we're not setting clock
V: attemping to drop administrator privileges
V: time is currently 1413241729.984579631
V: time is greater than RECENT_COMPILE_DATE
V: using TLSv1_client_method()
V: Using OpenSSL for SSL
V: opening socket to 10.152.152.10:9050
V: proxy5: connecting dtsxnd3ykn32ywv6.onion:80
V: proxy5: connect error 05 06
SSL connection failed
child process failed in SSL handshake

[ioerror]

Oh - I see - no - I am not interested in fetching time from HTTP only sites.

[adrelanos]

But .onion sites aren't HTTP only sites? Not a good way to push .onion? By using hidden services, we could avoid the SSL cartel and no longer be vulnerable to SSL CA compromises.

[ioerror]

tlsdate can't know that you're actually connecting to a real Tor
Hidden Service - it can only guess by the name. This is simply too
weak for me to consider at this time. It would require a Tor
controller and a Tor proxy for tlsdate to really verify that it was
actually working as expected.

I'd take a patch but I'd probably want to require a recompile. It is
dangerous and if you want - you can run a TLS site on the .onion and
pin the cert anyway.

[HulaHoopWhonix]

tlsdate can't know that you're actually connecting to a real Tor Hidden Service - it can only guess by the name.

I am not advocating for tlsdate to make smart decisions based on the commands we feed it, that approach would add unneeded complexity on many levels.

However I do think its valuable to allow optional use of SSL in tlsdate so it can work with this Tor based model.

This parameter wouldn't be used as a default and its unlikely that people who don't know what they are doing would poke into tlsdate's command line options in the first place to shoot themselves in the foot. But its very useful for those knowledgeable.

[ioerror]

You're advocating for not using TLS - thus it is just making a connection with HTTP - we are hoping that Tor is in use and that this is actually a valid .onion. There are two ways to do this - one is the easy way where we just say for foo.onion (or well formed .onions) that we allow HTTP rather than HTTPS/TLS. The harder way is with a Tor controller that confirms that tlsdate has indeed connected to a Tor hidden service. I'll take a patch for either but I really don't want a patch for the first one.

In any case, as it stands now, I'm not really interested in implementing this - please run a TLS service on the Tor HS if you want to use tlsdate with .onions at this time.

[HulaHoopWhonix]

You are welcoming for collaborative efforts and encourage patches for your project and for that I am thankful. Its not your fault that we don't know C - that's really our problem.

Therefore, any technical path to realize this feature in tlsdate is unlikely to happen. However there is one solution I can think of that can allow use of tlsdate as it is now for this purpose.

As a last ditch effort I am thinking about getting most of the the securedrop services that The Freedom of the Press Foundation set up for these organizations, to run SSL on their hidden services just so we can use it in that way. All these organizations already have clear net CA certificates that they paid for and use, all they'll need to do is deploy them on their HS servers too. Can I ask you to please put in a word for this request at TFPF? The odds are they will listen to someone with cred like you, than they ever will to me. Its a non-technical solution that is much easier and quicker to achieve than the alternatives. https://freedom.press/securedrop/directory

Is it ok if you do this favour for us? Can you please think about it?

please run a TLS service on the Tor HS if you want to use tlsdate with .onions at this time.

The problem with that it would be just our website - one point of failure that if comrpomised or denied service would screw all users. That's why we have to use other a number of other hidden services. That list from TFPF is great because before 2013, reliable, trusted and high traffic HS were non existant then.

If this goes through, we succeed in achieving a secure and accurate time source for a Torrified OS. A great achievement IMHO. After that I will tell TAILS about it so they can move to this better model for their users, by using tlsdate too.