Jupiter Broadcasting

Smarter Google DNS | TechSNAP 21

chris

Google and openDNS join forces to improve the speed of your downloads, find out what they are doing and how it works!

Plus gmail suffered another man in the middle attack, and Kernel.org gets some egg on their face!

All that and more, on this week’s episode of TechSNAP!

Direct Download Links:

HD Video | Large Video | Mobile Video | WebM Video | MP3 Audio | OGG Audio | YouTube

Subscribe via RSS and iTunes:

[ad#shownotes]

Show Notes:

Another SSL Certificate Authority Compromised, MitM Attack on Gmail

  • Sometime before July 10th, the Dutch Certificate Authority DigiNotar was compromised and the attackers we able to issue a number (apparently as many as 200) of fraudulent certificates, including a wildcard certificate for *.google.com. The attack was only detected by DigiNotar on July 19th. DigiNotar revoked the certificates, and an external security audit determined that all invalid certificates had been revoked. However, it seemed that probably the most important certificate, *.google.com was in fact not revoked. This raises serious questions and seems to point to a coverup by DigiNotar. Detailed Article Additional Article
  • Newer versions of Chrome were not effected, because Google specifically listed a small subset of CAs who would ever be allowed to issue a certificate for gmail. This also prevents self-signed certificates, which some users fall for regardless of the giant scary browser warning. Chrome Security Notes for June
  • Mozilla and the other browsers have taken more direct action disabled than they did with the Comodo compromise. All major browsers have entirely removed the the DigiNotar root certificate from their trust list. With the Comodo compromise, the effected certificates were blacklisted, but the rest of the Comodo CA was left untouched. One wonders if this was done as strong signal to all CAs that that must take security more seriously, or if DigiNotar was in fact cooperating with the Iranian government in its efforts to launch MitM attacks on its citizens. Mozilla Security Blog
  • Part of the issue is that some of the certificates issued were for the browser manufacturers them selves, such as Mozilla.org. With a fake certificate from Mozilla, it is possible that the MitM attack could block updates to your browser, or worse, feed you a spyware laden version of the browser.
  • Press Release from Parent Company VASCO
  • Pastebin of the fraudulent Certificate

  • Allan’s blog post about the previous CA compromise, and more detail than can fit even in an episode of TechSNAP
    *

    GoogleDNS and OpenDNS launch ‘A Faster Internet’

  • The site promoted a DNS protocol extension called edns-client-subnet that would have the recursive DNS server pass along the IP Subnet (not the full IP, for privacy) of the requesting client, to allow the authoritative DNS server to make a better Geo Targetting Decision.
  • A number of large content distributors and CDNs rely on GeoIP technology at DNS time to direct users to the nearest (and as such, usually fastest) server. However this approach is often defeated when a large portion of users are using GoogleDNS and OpenDNS and all of those requests come from a specific IP range. As this technology takes hold, it should make it possible for the Authoritative DNS servers to target the user rather than the Recursive DNS Server, resulting in more accurate results.
  • Internet Engineering Task Force Draft Specification
  • This change has already started effecting users, many users of services such as iTunes had complained of much slower download speeds when using Google or Open DNS. This was a result of being sent to a far-away node, and that node getting a disproportionate amount of the total load. Now that this DNS extension has started to come online and is backed by a number of major CDNs, it should alleviate the problem.

  • ScaleEngine is in the process of implementing this, and already has some test edns enabled authoritative name servers online.
    *

    Kernel.org Compromised

  • Attackers were able to compromise a number of Kernel.org machines
  • Attackers appear to have compromised a single user account, and then through unknown means, gained root access.
  • Attackers replaced the running OpenSSH server with a trojaned version, likely leaking the credentials of users who authenticated against it.
  • Kernel.org is working with the 448 people who have accounts there, to replace their passwords and SSH keys.
  • The attack was only discovered due to an extraneous error message about /dev/mem
  • Additional Article

Feedback:

Q: (DreamsVoid) I have a server setup, and I am wondering what it would take to setup a backup server, that would automatically take over if the first server were to go down. What are some of the ways I could accomplish this?

A: This is a rather lengthy answer, so I will actually break it apart, and have given one possible answer each week, for the last few weeks. This weeks solution is Anycast. This is by far the most complicated and resource intensive solution, but it is also the most scalable. Standard connections on the Internet are Unicast, meaning they go from a single point to another single point (typically, from a client to a specific server). The are also Broadcast (send to all nodes in the broadcast domain, such as your local LAN), and Multicast (send to a group of subscribed peers, used extensively by routers to distribute routing table updates, but does not work on the Internet). Anycast is different than a Unicast, instead of sending the packet to a specific host, the packet is sent to the nearest host (in network terms, hops, not necessarily geographic terms). The way Anycast works is your BGP enabled routers broadcast a route to your subnet to the Internet from each of the different locations, and the other routers on the Internet update their routing tables with the route to the location that is the fewest hops away. In this way, your traffic is diverted to the nearest location. If one of your locations goes down, when the other routers do not get an update from the downed router, they automatically change their route to the next nearest location. If you want only fail over, and not to distribute traffic geographically, you can have your routers prefix their routes with their own AS number a sufficient number of times to make the backup location always more hops than the main location, so it is only used if the main is down. There are some caveats with this solution, the first being that TCP packets were never meant to randomly redirect to another location, if a route change happens in the middle of an active session, that session will not exist at the second location, and the connection will be dropped. This makes Anycast unsuitable for long-lived connections, as routes on the Internet change constantly, routing around faults and congestion. Connections also cannot be made outbound from an Anycast IP, as the route back may end up going to a different server, and so a response will never be received, so servers would require a regular Unicast address, plus the Anycast address. A common solution to overcome the limitations of Anycast, is to do DNS (which is primarily UDP) via Anycast, and have each location serve a different version of the authoritative zone, which the local IP address of the web server, this way the users are routed to the nearest DNS server, which then returns the regular IP of the web server at the same location (this solution suffers from the same problems mentioned above in the Google DNS story). Another limitation is that due to the size of the address space on the Internet, most provides will not accept a route for a subnet smaller than a /24, meaning than an entire 256 ip address subnet must be dedicated to Anycast, and your servers will each require a regular address in a normal subnet. Broadcasting routes to the Internet also requires your own Autonomous System number, which are only granted to largish providers, or an ISP willing to announce your subnet on their AS number, but this requires a Letter of Authorization from the owner of the IP block.
*

ROUND-UP:

Bitcoin-Blaster: