https:// secure or threat on port 443?

[Erratus]

Most configurations open port 443 for browsing the internet as default. Most people think that they are on the safe side using HTTPS. Some realize, that there are quite many outgoing connections on 443 while browsing normal http://, NOT https://. This has become a normal scenario.

When locking 443 almost no errors occur while browsing the net (except of course when using shops and where logins have to be used). So what is streaming from your boxes?

Do you not care?

 

[kpa]

I'm not really following what you say. You can't connect to the internet without having a port "open" in the outgoing direction, in other words have means of sending data packets using the TCP protocol with destination port set to a specific number that identifies the service on the remote end. Should that number be 443 or 80, is that what you're asking?

 

[usdmatt]

I'm with @kpa, I really don't know what point you're trying to get at?

Most configurations open port 443 for browsing the internet as default.

If you are limiting outbound connections then I see only problems being caused by blocking outbound connections to port 443.

Most people think that they are on the safe side using https.

Unless something has changed, as far as I'm aware you're fairly safe submitting data to a website using HTTPS. The banks still seem happy enough with it.

Some realize, that there are quite many outgoing connections on 443 while browsing normal http:// NOT https:// - This has become a normal scenario.

I don't get this bit. It's highly unlikely that you will see outgoing connections with a destination port of 443 which are not HTTPS connections. It's definitely not a 'normal' scenario. If users are concerned about whether a website they are currently on is secure, browsers provide a simple way to tell if your current connection is secure or not - usually a padlock symbol - all users should be aware of this.

When locking 443 almost no errors occur while browsing the net (except of course when using shops and where logins have to be used). So what is streaming from your boxes?

Do not care?

Assuming you're configuring a firewall, why would you ever purposefully block access to SSL enabled websites? We're getting to the point now where it's generally encouraged to access any website that you may send information to over SSL. It definitely an extremely strange choice to block SSL website access in the name of security.

 

[Erratus]

My point is, that if you browse i.e. http://www.example.com you may find a bunch of traffic going outbound 123.123.123.123:443 (url and numbers are just i.e.) which may not resolve to example.com. And you do not know what is going encrypted out of your box.

Just have a look with tcpdump on your interface and grep :443 and you know what I mean.

 

[kpa]

No I don't know what you mean. Give us a log of such a session and we can take a look and decide whether it is something to be concerned about or not.

 

[DutchDaemon]

It is very likely that that is any of these things: one or more browsers syncing your settings (e.g. Chromium), one or more of your browser plugins contacting your browser's app stores for updates (e.g. Mozilla is https-only), any network-aware and running app phoning home for updates, any Google app (a Gmail-checker, a GooglePlus Notification app, Google Docs, etc.). Web browsers with prefetch turned on (links from current web page are being loaded in the background). There is a huge amount of 'back alley traffic' on any reasonably loaded desktop environment. On a dedicated server, yes, I'd be wary. But any desktop with one or more browser tabs open will start showing outbound connections.

 

[kpa]

There are also many pages with mixed content, some http and some https. Most browsers should warn about such pages nowadays. Also when the pages have scripts embedded they can create all kinds of requests for content that have no relation to the origin page.

 

[ShelLuser]

Just have a look with tcpdump on your interface and grep :443 and you know what I mean.

Actually I think you should consider trying out IPTraf, or perhaps something easier like net/pftop or perhaps # ipfstat -tCD any,443 (depending on your firewall setup I assume).

If you then try www/lynx, which is a very minimalistic text-only web browser, and point it to something such as https://google.nl then you may end up surprised. If you're using google.com then you may get a situation similar to the one you described, but that's merely because google.com will redirect you to a localized version of their website.

Oh, I'd also recommend using sysutils/screen for experiments like this, it allows you to do all this using one single console.

Alas, if you do this then you'll notice a single connection which involves port 443. From a non-privileged port on your machine to port 443 on the remote, and back again.

Whatever you're seeing on your computer it really has nothing to do with the way the https protocol works, but more so with your (browser) environment and possibly the encrypted website you're using.

 

[Erratus]

Sometimes it's hard to get an understanding, but

when the pages have scripts embedded they can create all kinds of requests for content that have no relation to the origin page.

This is exactly what creates these connections on port 443 here. I have been running Squid and Privoxy for a while, quite restrictively configured and optically free of ad-junk. To me it was a surprise when I looked at the DNS-Hitlist and then discovered that there is still a lot of unrelated traffic, most of that generated through 443.

Over 90% of net traffic found to be unrelated to the intended use, mostly caused by social media junk and Googles & Co.

This was the time when closed port 443 for outgoing traffic only to discover that the IPv4 firewall was bypassed by IPv6. To me it looks like there is war on the other end of the cable that generates revenues to others.

 

[Anonymous]

This is exactly what creates these connections on port 443 here. I have been running Squid and Privoxy for a while, quite restrictively configured and optically free of ad-junk. To me it was a surprise when I looked at the DNS-Hitlist and then discovered that there is still a lot of unrelated traffic, most of that generated through 443.

The DoNotTrackMe Browser Plugin from Abine Inc. works for me. There is also a Firefox plugin, however, I cannot tell if this works well, because I am on Mac OS X Safari.

 

[Erratus]

Some of you asked for an example for the outgoing encrypted traffic on 443. This example is showing you how http://www.guardian.co.uk/ is not only mining data while surfing their website, but also spying on your LAN infrastructure:

HTML-Snippet found on http://www.guardian.co.uk

 <div class="soulmate component two-col edge">
	<div class="hd"><h3 class="t5"><a href="https://soulmates.guardian.co.uk?INTCMP=sm_promo">Online dating</a></h3></div>
	<p><a class="soulmate-image-link" href="https://soulmates.guardian.co.uk/landing/515d6ba35e5db3f0fed271f6?INTCMP=sm_promo" >
		<img src="https://dqwufkbc3sdtr.cloudfront.net/members/515d6ba35e5db3f0fed271f6/small.png" title="" width="60" alt="" /></a>
		<a href="https://soulmates.guardian.co.uk/landing/515d6ba35e5db3f0fed271f6?INTCMP=sm_promo">Find your soulmate with the Guardian's dating site</a>
	</p>
	<p class="slotfooter"><a href="https://soulmates.guardian.co.uk?INTCMP=sm_promo">Join Guardian Soulmates</a></p>
</div>

Resulting in a tunnel to dqwufkbc3sdtr.cloudfront.net:443

CONNECT dqwufkbc3sdtr.cloudfront.net:443 HTTP/1.0
User-Agent: Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.1; WOW64; Trident/6.0)
Host: dqwufkbc3sdtr.cloudfront.net
Content-Length: 0
DNT: 1
Proxy-Connection: Keep-Alive
Pragma: no-cache

Decrypted content of that tunnel:

<html><head><title>The Proxomitron Reveals...</title>
<base href="http://Local.Ptron/">
<link rel="stylesheet" type="text/css" href="Errors.css">
<script type="text/javascript" src="Errors.js"></script>
</head> <body>
<div id="d1"></div><div id="d2"></div><div id="d3"></div><div id="d4"></div>
<div id="block1">
<img src="ErrLogo.png" id="i1">
<div id="block2"> 
<h1 id="e1">CONNECT method not supported</h1>  
<div id="e2">
The following proxy...
<div id="e3"> 172.17.XXX.XXX</div>
Doesn't appear to support this method.
</div>
   </div>
</div>
<div id="d5"></div>
</body></html>

This leaks the used proxy and it's LAN-IP to cloudfront.net. Without knowing who analyses this data and for what purpose.

 

[ShelLuser]

Some of you asked for an example for the outgoing encrypted traffic on 443. This example is showing you how http://www.guardian.co.uk/ is not only mining data while surfing their website, but also spying on your LAN infrastructure.

To be honest I'm seeing something else.

What I can spot in that HTML snippet is that this website is using <div> sections which contain advertisement. It's not uncommon for websites like this to retrieve that information from a central location, in this case from the host soulmates.guardian.com. And because it's doing this over encrypted channels you end up with multiple connections.

In a way this is comparable to my earlier example where I hinted that if you pointed a browser to https://google.com you'd also end up with multiple connections because the website will redirect you to a local mirror.

Resulting in a tunnel to dqwufkbc3sdtr.cloudfront.net:443

It's not. Its merely an extra HTTPS connection which was initiated by the website. This is no different from a web page which embeds pictures located on another server, or a web page which contains an embedded YouTube player.

In both cases your browser is going to open connections to those other locations as well, simply because the web page pointed it there.

There is no proxy, no tunnel and certainly no spying, at least not here. There isn't even any Javascript involved with this, which is normally the first step in tracking (one of the reason's why I have google-analytics.com permanently marked as untrusted in my NoScript plugin).

No offense but I think you're seeing more than there actually is.

 

[ShelLuser]

Right, so I started to dig a little more and I can now see where your previous comment regarding a tunnel came from. I still don't agree that this is a tunnel, but I now fully understand where it's coming from because from what I can tell (I can't be 100% sure because I have no intentions to start sending all sorts of probes towards the Guardian (the sentence alone makes it sound like a bad idea :e)) there is indeed a proxy involved.

However; a proxy works both ways. It's not merely a gateway which is used to give several internal clients controlled access to another network. The technique is also often used to spread incoming requests from external clients onto a selection of internal servers, for example a cluster of web servers.

I think that's what you may have seen up there. Not so much a proxy going from your network to theirs (I can honestly understand any possible confusion), but a proxy which relays your request for any web contents to one of the many (?) internal web servers which are assigned to relay the requests in order to spread the load.

Like I mentioned earlier this is only a theory of mine, but one I base on several very specific hints.

 

[gkontos]

What you see as outgoing HTTPS traffic is the tracking code that most sites use. Either use some tool like @rolfheinrich suggested or filter those requests on a local or LAN proxy.

 

[CoTones]

DoNotTrackMe Browser Plugin from Abine Inc. is closed source and their shiny page "We protect you - no information for non idiots available" seems poor choice.

 

[Anonymous]

DoNotTrackMe Browser Plugin from Abine Inc. is closed source ...

This is not exactly true. Those Plugins are mainly Javascript, some CSS, and HTML, that you can browse. On my Mac I did the following in Terminal, and I guess that similar things can be done on FreeBSD too:

$ cd ~/Desktop
$ cp ~/Library/Safari/Extensions/DoNotTrackMe.safariextz DoNotTrackMe.safariextz
$ xar -x -f DoNotTrackMe.safariextz 
$ ls -R webkit.safariextension

Icon-128.png	Icon-48.png	Icon.png	Settings.plist	chrome
Icon-16.png	Icon-64.png	Info.plist	_locales	webkit

webkit.safariextension/_locales:
de	en	es	fr	it	nl	pl	pt_BR	pt_PT	sv

webkit.safariextension/_locales/de:
messages.json

webkit.safariextension/_locales/en:
messages.json

webkit.safariextension/_locales/es:
messages.json

webkit.safariextension/_locales/fr:
messages.json

webkit.safariextension/_locales/it:
messages.json

webkit.safariextension/_locales/nl:
messages.json

webkit.safariextension/_locales/pl:
messages.json

webkit.safariextension/_locales/pt_BR:
messages.json

webkit.safariextension/_locales/pt_PT:
messages.json

webkit.safariextension/_locales/sv:
messages.json

webkit.safariextension/chrome:
content

webkit.safariextension/chrome/content:
BadgeManager.js		lib			themes
badTrackers.js		notificationManager.js	view.js
common.js		optout.js		view_alert.js
css			rules.js		view_allowed_sites.js
events.js		socialButtons.js	view_global.js
fonts			template.js
images			templates

webkit.safariextension/chrome/content/css:
popup.css

webkit.safariextension/chrome/content/fonts:
League_Gothic.otf

webkit.safariextension/chrome/content/images:
abine-off.png			logo-big.png
accept.gif			logo.png
adnetworks.png			my-exception-icon.png
at_symbol.png			plusone.PNG
badge				plusone_blocked.PNG
bg-black-bar.png		pointer-legend.png
black-list-bg.png		pointer.png
cancel.gif			privacy_alert_toolbar.png
close-blue.png			safead.gif
counter				social.png
cross.gif			stats.png
default-setting-icon.png	stopsign_cancel.gif
dial.png			sunrise.png
facebook.png			thumbs-down-sprite.png
google.png			thumbs-up-sprite.png
greenicon.png			trackers.png
header.png			triangle.png
like.PNG			tv_icon.png
like_blocked.PNG		tweet.PNG
linked-in.png			tweet_blocked.PNG
linkedin.PNG			twitter.png
linkedin_blocked.PNG		white-list-bg.png

webkit.safariextension/chrome/content/images/badge:
badge_box_bg.png	gold-sm.png		platinum.png
bronze-sm.png		gold.png		silver-sm.png
bronze.png		platinum-sm.png		silver.png

webkit.safariextension/chrome/content/images/counter:
green.png	red.png		yellow.png

webkit.safariextension/chrome/content/lib:
jqplot.barRenderer.min.js		jqplot.categoryAxisRenderer.min.js
jqplot.bubbleRenderer.min.js		jqplot.highlighter.min.js
jqplot.canvasAxisLabelRenderer.min.js	jqplot.min.css
jqplot.canvasAxisTickRenderer.min.js	jquery.jqplot.min.js
jqplot.canvasTextRenderer.min.js	jquery.min.js

webkit.safariextension/chrome/content/templates:
all.js

webkit.safariextension/chrome/content/themes:
light

webkit.safariextension/chrome/content/themes/light:
css		images		templates	webkit.html

webkit.safariextension/chrome/content/themes/light/css:
popup-ie.css		popup-webkit.css	popup.css

webkit.safariextension/chrome/content/themes/light/images:
alert.png		fb_sm.png		question.png
at_symbol.png		footer-button-bg.png	settings.png
badge			footer-del-me.png	social-green.png
circle_red_glow.png	footer-mask-me.png	social-red.png
circle_red_pressed.png	gear.png		social-yellow.png
close.png		google.png		stats.png
company-green.png	header-bg.png		sun.png
company-red.png		linked-in.png		tv-icon.png
company-yellow.png	logo.png		tw_sm.png
cross.gif		on-off-knob.png		twitter.png
facebook.png		on-off.png

webkit.safariextension/chrome/content/themes/light/images/badge:
bronze-sm.png	gold-sm.png	platinum-sm.png	silver-sm.png
bronze.png	gold.png	platinum.png	silver.png

webkit.safariextension/chrome/content/themes/light/templates:

webkit.safariextension/webkit:
background.js	css		load-popup.js	popup.js	view.js
common.js	inpage.js	popup.html	safari		view_alert.js

webkit.safariextension/webkit/css:
popup.css

webkit.safariextension/webkit/safari:
background.html	global.js	view_alert.js
content.js	images		view_tooltip.js

webkit.safariextension/webkit/safari/images:
icon-safari-off.png			safari-badge.png
icon-safari.png				safari-icon.png
privacy_alert_toolbar_safari.png

After adding line-breaks and spaces, the JavaScript is readable.

... and their shiny page "We protect you - no information for non idiots available" seems poor choice.

This is simply U.S. style of advertisement, it's part of the culture and Europeans don't like it too much, however, it is in no way an indication of notourious lying, but Europeans may want to simply accept if not respect it.

Anyway, non-idots/non-believers have a chance to find out, whether the DoNotTrackMe plugin does bad things or not. I for my part omitted an in-deep analyses, I only browsed the contents of the files.

I know for sure that the Trackers do things that I don't want. I assume that DoNotTrackMe does not. So the conclusion for me is clear, it's less risky to use DoNotTrackMe.

BTW: People who understand the German language might want to read this funny and instructive BLOG-Post at faz.net:
Lasst uns zuerst alle NSA-Tracker töten

(eng.: The first thing we do, let’s kill all the NSA-Trackers. -- based on Shakespeare's "... kill all the lawyers.").

 

[Anonymous]

What you see as outgoing HTTPS traffic is the tracking code that most sites use. Either use some tool like @rolfheinrich suggested or filter those requests on a local or LAN proxy.

Yes, this traffic is imposed by the trackers, sorry, I assumed that this was clear, but obviously it was not. The Guardian makes excessive use of them, up-to 12 on one page.

 

[gkontos]

Yes, this traffic is imposed by the trackers, sorry, I assumed that this was clear, but obviously it was not. The Guardian makes excessive use of them, up-to 12 on one page.

Right, I was just looking at them. It also appears that they are using CDN for delivering their content which justifies that in a sense.

 

[cpm@]

Right, I was just looking at them. It also appears that they are using CDN for delivering their content which justifies that in a sense.

Yes, http://www.guardian.co.uk uses a content-delivery network (CDN) called Amazon CloudFront. To speed websites up, it is best to host the resources for that site (images, CSS and Javascript files and so on) in the nearest geographical proximity to the user. So if a visitor is, say, in the UK, then CloudFront will serve up files from the UK. As this made sites faster, particularly sites with a lot of load (i.e. The Guardian).

See also Guardian Case Study: AWS as example of use Amazon for business purposes.