Post reply

Name:
Email:
Subject:
Message icon:

Verification:
Type the letters shown in the picture
Listen to the letters / Request another image

Type the letters shown in the picture:
Second Anti-Bot trap, type or simply copy-paste below (only the red letters):www.scforum.info:

shortcuts: hit alt+s to submit/post or alt+p to preview


Topic Summary

Posted by: krishna88
« on: 22. November 2017., 11:00:33 »

Hi @Samker,

Thanks for sharing the important information about how HTTP and HTTPS works.

Cheers!!
Posted by: Samker
« on: 01. October 2016., 09:08:52 »

Posted by: gicc chan
« on: 29. September 2016., 15:03:31 »

HTTPS Inspection?
Posted by: devnullius
« on: 11. January 2015., 22:08:30 »

Strange nobody else thought of this before! Kinda worrying... With governments in my mind :/

Devvie
Posted by: Samker
« on: 06. January 2015., 17:52:01 »



A UK consultant has demonstrated how a feature of the secure Web protocol HTTPS can be turned into a tracking feature that is, in the case of some browsers, ineradicable.

HTTP Strict Transport Security (HSTS), described in RFC 6797 (here: http://tools.ietf.org/html/rfc6797 ), is a mechanism that helps sites redirect users from the insecure HTTP version to the encrypted HTTPS version. If a user puts http://www.google.com into their browser, it's HSTS that sends them to https://www.google.com.

The problem is, someone thought it might be troublesome if the User Agent – that is, your browser – had to go through a redirect every time a user visited the https: site. So the authors of HSTS created a mechanism for browsers to remember the HSTS policy of sites they've visited.

That's what Sam Greenhalgh has identified as a kind of super-cookie, here: http://www.radicalresearch.co.uk/lab/hstssupercookies
His point is that an HSTS “pin” is set for each HTTPS-redirected site you use, it's unique to user and site, and it's readable from your browser settings by any site.

“Once the number is stored it could be read by other sites in the future. Reading the number just requires testing if requests for the same web addresses are redirected or not,” Greenhalgh writes.

Nor do “private” or “incognito” browsing modes help.

Greenhalgh notes that some browsers allow the HSTS flags to be cleared, so that in Chrome, Firefox and Opera the issue is mitigated somewhat (IE doesn't support HSTS).

Safari is the killer, though: “When using Safari on an Apple device there appears to be no way that HSTS flags can be cleared by the user. HSTS flags are even synced with the iCloud service so they will be restored if the device is wiped. In this case the device can effectively be 'branded' with an indelible tracking value that you have no way of removing.”

It's a trick that needs a malicious site owner for an exploit. Greenhalgh also notes that the issue was described in 2012 by Mikhail Davidov here: http://www.leviathansecurity.com/blog/the-double-edged-sword-of-hsts-persistence-and-privacy/ , calling implementation by a site owner “nearly trivial”

Google has told Greenhalgh that “defeating such fingerprinting is likely not practical without fundamental changes to how the Web works”, which seems odd to El Reg since IE manages to navigate the Web without supporting HSTS at all.

Of course, it could merely be that Google feels some investment in HSTS, since its Adam Barth is one of RFC 6797's three authors.

(ElReg)
Enter your email address to receive daily email with 'SCforum.info - Samker's Computer Forum' newest content:

Terms of Use | Privacy Policy | Advertising