This is useful for several reasons. It means your employees aren't constantly fighting browser warnings when trying to submit stuff internally. All your http traffic is encrypted. You don't need to install a self-generated root certificate on devices. Lovely!

But there's a downside. Every TLS certificate created by Let's Encrypt is recorded in a Certificate Transparency log. These CT logs are primarily to detect maliciously or mistakenly issued certificates. For example, you can look through them and see that someone unauthorised has created a cert for your domain - or its sub-domains.

But there is a downside. The CT logs are public and can be searched. Here's all the certificates issued for Twitter's sub-domains.

There are a few ways that this can be dangerous for use with internal services.

Firstly, it aides reconnaissance for attackers. Having a "map" of your internal infrastructure is useful. Especially if you have "obviously" named servers like exchange.example.com or customerdata.example.com. Also handy for social engineering - who else but someone internal would know that gandalf.example.com was a valid server?

Secondly, it might expose some vulnerabilities - depending on how you name things. Let's hope you don't have log4j.example.com!

Thirdly, there's the potential for espionage. Do you want your competitors knowing that you've got olympics-campaign.staging.example.com?

I'm sure you can think of a few other ways this could be used for mischief and mayhem.

As I wrote a few years ago, "There's no HTTPS for the Internet of Things". Internal networks which only have IP addresses cannot use TLS certificates. OK, so you decide to have an internal DNS - now the whole world knows you have doorbell-model-xyz.myhome.example.com!

The only real answer to this is to use Wildcard Certificates. You can get a TLS certificate for *.internal.example.com

This requires setting up a DNS-01 Challenge - which can be more difficult to configure and has some non-obvious risks. And, sadly, Wildcard certificates come with their own difficulties.

Recap

I don't think there's a good solution to this.

• Self-signed certificates require something to be installed on all clients. Not always possible with BYOD.
• Named LE certificates expose details of your infrastructure which you may wish to keep private.
• Wildcard certificates require a heightened level of co-ordination and management.

These problems have all been discussed before. But I can't help but wishing that there was something obvious I'm missing.

How would you solve this knotty problem?

The email I received from Reddit was charmingly lo-fi and eschewed those bourgeois capital letters.

Notice the (teensy tiny) flaw? Yup, it's using vanilla "http" rather than the super secure "https".

Earlier this year, Reddit switched on SSL for their entire site. Somewhat annoyingly though, they do not force SSL for the site. If you want to ensure all your sessions are encrypted, you have to manually set it up in your preferences.

I find that a little disappointing. I know that there is a cost associated with 100% SSL coverage on a major site like Reddit, but surely because of the site's popularity they should mandate it?

Anyway, I reported this minor problem to the security email address listed on their bugs page. A few minutes later, they replied.

Thanks for the report! While I don't believe there's any vulnerability introduced if we leak the verification token here (being that the intended recipient must have wanted to verify it if they clicked it, and tokens are tied to both the email and account,) I've got a fix for this that should go out this week.

A day or two later and it was fixed.

I'm trying really hard to come up with a malicious use for a MITM attack on this. There's not much.

The "dest" parameter doesn't appear to be hackable. It won't point to any site other than Reddit. So you can't redirect the user to a malicious site. What you can do is redirect to any Reddit post or page. Perhaps sending someone to a particularly disgusting post could be legally disadvantageous?

Of course, a malicious actor on the network could sniff the user's login credentials if the user hadn't noticed the lack of HTTPS.

So, there we are. A minor bug, swiftly fixed - and a general reminder that when you switch on HTTPS, make sure all of your communications with your users are updated to reflect that fact.

I've been trying to mount an OwnCloud instance via WebDAV. I kept receiving the error

Mounting failed. SSL handshake failed: SSL error: sslv3 alert handshake failure

Or

SSL handshake failed: SSL alert received: Handshake failed

The route of this problem seems to be that the version of libneon (the WebDAVS connector library) shipped with Ubuntu 12.04 doesn't play nicely with the SSL certificates issued by CloudFlare.

Here's the solution I discovered.

Grab libneon 30.1 - and extract it to a directory.

Compile

./configure --prefix=/usr --enable-shared --with-ssl=openssl --disable-static
make
sudo make install

We now need to replace the old libneon-gnutls.so - and we want the end result to look like

/usr/lib/libneon-gnutls.so.27 -> /usr/lib/libneon.so.27
/usr/lib/libneon.so -> libneon.so.27.3.1
/usr/lib/libneon.so.27 -> libneon.so.27.3.1

First, back up the old version.

sudo mv /usr/lib/libneon-gnutls.so.27 /usr/lib/libneon-gnutls.so.27.old

Then, in /usr/lib/

sudo ln -s /usr/lib/libneon.so.27.3.1 libneon.so.27
sudo ln -s /usr/lib/libneon-gnutls.so.27.3.1 libneon.so
sudo ln -s /usr/lib/libneon.so.27 libneon-gnutls.so.27

Then, to mount the directory.

sudo mount -t davfs -o uid=me,gid=users https://example/owncloud/remote.php/webdav/ /mount/remote

(Where "me" is your user name.)

That made everything work!

Most of the app's communication with the Path servers is over SSL. This means that no-one can see the data you're sending and receiving. If there are snoops on your network, they will only be able to see the encrypted data flowing back and forth. In general, this is a good thing.

Apart from images. If your friends are posting images, they are sent over http. No security. Anyone monitoring your network connection will be able to see all the images you're viewing.

Now, that's bad enough - but it turns out that all the images you send are visible to the the world even if you've set your post to private.

The images are sent over SSL, but as soon as you return to your "Path", a thumbnail is shown of what you've just posted!

Here's a picture of the logs, so you can see what's happening.

So, every image you post or see - including the avatars of your friends - are visible to all. A rather serious security and privacy problem.

Oh, does anyone know what the unencrypted call to "sendgrid.net" is all about?

Twitter's secure API hides the contents of the tweets you are reading. But it doesn't hide the images of those you converse with.

Raised as Issue 2175.

A Bit More Detail

Twitter has a secure (HTTPS) and insecure (HTTP) API.

When calling the secure API, all the content of the returned message (tweets) are encrypted. Eavesdroppers only see the cipher-text - essentially garbage.

However, within that cipher-text are links to insecure resources.

For example, a user requesting my tweets will get an object which contains a link to my avatar image.

Twitter is currently returning the insecure link:

"profile_image_url" :
    "http://a2.twimg.com/profile_images/1283757621/Sketch_Avatar.jpg"

Twitter should be returning the secure link:

"profile_image_url" :
    "https://si0.twimg.com/profile_images/1283757621/Sketch_Avatar.jpg"

Exploiting This Weakness

A user (Anna) will request the encrypted text of my tweets She then requests the unencrypted image. An eavesdropper (Eve) is listening in on the connection between Anna and Twitter.

Anna ---->Eve---->Twitter  (Secure request)
Anna <----Eve<----Twitter  (Secure response)

When Anna makes the initial request to Twitter, the malicious Eve can't see what they're talking about.

• The request "https://example.com/twitter/edent" is itself encrypted. Eve only sees an encrypted request to example.com - not "twitter/edent
• The response containing all the tweets is also encrypted

Anna ---->Eve---->Images  (insecure request)
Anna <----Eve<----Twitter  (insecure response)

Anna then makes the subsequent request for the twitter user's image, a malicious user can see

• The URI of the request.
• The content of the image.

Impact

Truth is, this has a pretty low security impact.

• There is no way to determine a user's name based on the URI for their image. (Unless you already have both).
• An eavesdropper has no way of knowing if the image is from the timeline, a reply, a DM, a search, a retweet, or the public timeline.
• Images may be locally cached by the user's browser - so frequency analysis isn't reliable.
• A malicious user could alter the image in transit.

Worst case scenario is that if a malicious man-in-the-middle knows which images relate to which Twitter users, they know the intercepted user has seen at least one tweet from that user.

Let's say Anna is communicating with Bob. Eve is trying to eavesdrop. If Bob has never tweeted, and Eve sees repeated requests from Anna for Bob's avatar, she may reasonably surmise that they are exchanging DMs.

Overall

This is a pretty low-impact privacy risk. It can be fixed by Twitter's API returning HTTPS URIs where possible. In the meantime, developers can replace "http://a2.twimg.com/" with "https://si0.twimg.com".