Entries Tagged "Safari"

Page 1 of 1

Apple Will Offer Onion Routing for iCloud/Safari Users

At this year’s Apple Worldwide Developer Conference, Apple announced something called “iCloud Private Relay.” That’s basically its private version of onion routing, which is what Tor does.

Privacy Relay is built into both the forthcoming iOS and MacOS versions, but it will only work if you’re an iCloud Plus subscriber and you have it enabled from within your iCloud settings.

Once it’s enabled and you open Safari to browse, Private Relay splits up two pieces of information that—when delivered to websites together as normal—could quickly identify you. Those are your IP address (who and exactly where you are) and your DNS request (the address of the website you want, in numeric form).

Once the two pieces of information are split, Private Relay encrypts your DNS request and sends both the IP address and now-encrypted DNS request to an Apple proxy server. This is the first of two stops your traffic will make before you see a website. At this point, Apple has already handed over the encryption keys to the third party running the second of the two stops, so Apple can’t see what website you’re trying to access with your encrypted DNS request. All Apple can see is your IP address.

Although it has received both your IP address and encrypted DNS request, Apple’s server doesn’t send your original IP address to the second stop. Instead, it gives you an anonymous IP address that is approximately associated with your general region or city.

Not available in China, of course—and also Belarus, Colombia, Egypt, Kazakhstan, Saudi Arabia, South Africa, Turkmenistan, Uganda, and the Philippines.

Posted on June 22, 2021 at 6:54 AM • View Comments

UAE Man-in-the-Middle Attack Against SSL

Interesting:

Who are these certificate authorities? At the beginning of Web history, there were only a handful of companies, like Verisign, Equifax, and Thawte, that made near-monopoly profits from being the only providers trusted by Internet Explorer or Netscape Navigator. But over time, browsers have trusted more and more organizations to verify Web sites. Safari and Firefox now trust more than 60 separate certificate authorities by default. Microsoft’s software trusts more than 100 private and government institutions.

Disturbingly, some of these trusted certificate authorities have decided to delegate their powers to yet more organizations, which aren’t tracked or audited by browser companies. By scouring the Net for certificates, security researchers have uncovered more than 600 groups who, through such delegation, are now also automatically trusted by most browsers, including the Department of Homeland Security, Google, and Ford Motors­and a UAE mobile phone company called Etisalat.

In 2005, a company called CyberTrust­—which has since been purchased by Verizon­—gave Etisalat, the government-connected mobile company in the UAE, the right to verify that a site is valid. Here’s why this is trouble: Since browsers now automatically trust Etisalat to confirm a site’s identity, the company has the potential ability to fake a secure connection to any site Etisalat subscribers might visit using a man-in-the-middle scheme.

EDITED TO ADD (9/14): EFF has gotten involved.

Posted on September 3, 2010 at 6:27 AM • View Comments

Detecting Browser History

Interesting research.

Main results:

[…]

  • We analyzed the results from over a quarter of a million people who ran our tests in the last few months, and found that we can detect browsing histories for over 76% of them. All major browsers allow their users’ history to be detected, but it seems that users of the more modern browsers such as Safari and Chrome are more affected; we detected visited sites for 82% of Safari users and 94% of Chrome users.

    […]

  • While our tests were quite limited, for our test of 5000 most popular websites, we detected an average of 63 visited locations (13 sites and 50 subpages on those sites); the medians were 8 and 17 respectively.
  • Almost 10% of our visitors had over 30 visited sites and 120 subpages detected—heavy Internet users who don’t protect themselves are more affected than others.

    […]

  • The ability to detect visitors’ browsing history requires just a few lines of code. Armed with a list of websites to check for, a malicious webmaster can scan over 25 thousand links per second (1.5 million links per minute) in almost every recent browser.
  • Most websites and pages you view in your browser can be detected as long as they are kept in your history. Almost every address that was in your browser’s address bar can be detected (this includes most pages, including those retrieved using https and some forms with potentialy private information such as your zipcode or search query). Pages won’t be detected when they expire from your history (usually after a month or two), or if you manually clear it.

For now, the only way to fix the issue is to constantly clear browsing history or use private browsing modes. The first browser to prevent this trick in a default installation (Firefox 4.0) is supposed to come out in October.

Here’s a link to the paper.

Posted on May 20, 2010 at 1:28 PM • View Comments

A Month of Browser Bugs

To kick off his new Browser Fun blog, H.D. Moore began with “A Month of Browser Bugs”:

This blog will serve as a dumping ground for browser-based security research and vulnerability disclosure. To kick off this blog, we are announcing the Month of Browser Bugs (MoBB), where we will publish a new browser hack, every day, for the entire month of July. The hacks we publish are carefully chosen to demonstrate a concept without disclosing a direct path to remote code execution. Enjoy!

Thirty-one days, and thirty-one hacks later, the blog lists exploits against all the major browsers:

  • Internet Explorer: 25
  • Mozilla: 2
  • Safari: 2
  • Opera: 1
  • Konqueror: 1

My guess is that he could have gone on for another month without any problem, and possibly could produce a new browser bug a day indefinitely.

The moral here isn’t that IE is less secure than the other browsers, although I certainly believe that. The moral is that coding standards are so bad that security flaws are this common.

Eric Rescorla argues that it’s a waste of time to find and fix new security holes, because so many of them still remain and the software’s security isn’t improved. I think he has a point. (Note: this is not to say that it’s a waste of time to fix the security holes found and publicly exploited by the bad guys. The question Eric tries to answer is whether or not it is worth it for the security community to find new security holes.)

Another commentary is here.

Posted on August 3, 2006 at 1:53 PM • View Comments

Sidebar photo of Bruce Schneier by Joe MacInnis.