August 2009 Archives

I joined four other Seattle-area Tesla owners in driving down to Portland for the NEDRA Wayland Invitational IV electric vehicle drag racing event at Portland International Raceways on July 24th and 25th. My friend Richard wasn't due to receive his 2010 Roadster for another week or two, so he and I shared the driving and the racing in my car.

None of us had any previous drag racing experience, we were just doing it to promote electric vehicles by showing a bunch of people that EVs can be as fun and powerful as gas-burners without sending a bunch of our our dollars overseas or dumping CO2 into the atmosphere.

Over the two days, thanks to Northwest Handling Systems, John Wayland, James Morrison, and several others behind the scenes, who arranged charging both on and off the track, I was able to post the best time in a 2008 Roadster: a 12.982 second 1/4 mile ET at 103.48 mph. The best Roadster time was set by Scotty Pollacheck (the professional driver/rider of the famous Killacycle) in James Morrison's freshly-delivered 2010 Roadster sport: 12.643 second 1/4 mile ET at 102.89 mph.

At the Wayland Invitational, I got to race head-to-head against other 2008 Roadsters using the same driving technique and as well as controlling other parameters. Having Richard racing in my car allowed me to compare how weight changed times with other parameters held constant. Also got to race against the famous White Zombie. We had two nights there, one with charging at the track and one without. My YouTube channel has some videos from that weekend.

Two weeks later, the same group of owners spent another evening at Pacific Raceways in Kent, WA this time with Richard driving his shiny new 2010 Roadster. I was able to do some more experiments there.

Based on what I've seen so far, it breaks down like this:

13.40 seconds: 2008 Roadster, medium weight driver with a cool battery pack, single foot start, traction control on, racing in warm weather at sea level.

0.32 seconds - having a warm battery pack from a recent 240V/40A charge
0.10 seconds - traction control off
0.07 seconds - lose 20 to 30 lbs of driver weight
0.07 seconds - two-footed start (indirect estimate)

I didn't compare single foot launch and two-foot launch with all other parameters controlled. From otherwise similar runs in Portland and Kent, I saw a difference of about 0.07 seconds, but that was different tracks, different charge profiles and different ambient temperatures. The other delta were pretty well controlled.

One owner in Portland increased tire pressure to 40 psi all around trying to shave off a few hundredths to break into the high 12's and didn't get any benefit.

There's also some variation from car to car depending on how well the motor was wound, etc. While there was about 0.07 seconds difference between Richard and me in my car (presumably due to weight), there was a much smaller difference between Scott in his car and me in mine (0.04 seconds) even though I would guess the weight difference to be similar.

I didn't sense the stock tires spinning even with a two-foot launch and TC off, so I don't see how sticky tires would help on a 2008 Roadster. I have confirmation from Tesla to not expect the 2008 Roadster to spin the stock tires with TC off when on dry pavement and driving in a straight line. (That said, I am not recommending turning off TC in any other circumstance.)

I didn't get a chance to try all of the optimizations on the same run. It was only on the second day of the Wayland Invitational that I had a chance to charge up at the track and that was before I learned about the two-foot launch technique in detail, and also before I had the nerve to turn off traction control. So, I don't know what happens when you stack up all of the techniques together.

According to my data, getting a stock 2008 Roadster under 12.8 is going to take a trick I don't know about. Perhaps a driver under 100 lbs, or driving at higher altitude could do it. It might also help to fold back the side mirrors to reduce drag. It will be interesting to see what happens at the NEDRA nationals in Denver in September.

DEFCON is an annual computer security conference, the inexpensive and unruly counterpart to the more expensive corporate Black Hat security conference. From computer security briefings to the toxic barbeque to lock picking contests to a 52-hour competition to turn the electric conference badge into something more by any available means, DEFCON has something for everyone.

My focus is generally attending the briefings on computer security, privacy and civil rights issues, but even that consists of five parallel tracks of concurrent talks, so I only get to see a fraction of what's being presented.

That said, here's my summary of what I learned this year.

Picking the Lock on Your Browser

I trust everyone knows that when you're entering sensitive personal information, like bank account and credit card numbers, into a web page you need to look for the little lock icon so that you know you aren't revealing your info to some malicious criminal. Technically speaking, the lock (along with the https:// in the address bar) guarantees that you are sending that info to the web site you intend (not some malicious forgery) and that the info is being sent in an encrypted form so that even if a criminal is recording all of the data as it is transmitted across the Internet, your private information can't be read.

For the lock to be effective, you need to make sure you entered the correct address into your browser. Getting you to enter an incorrect address is the basis of what is called "phishing." One example of phishing is sending fake email messages that look like they came from your bank, or eBay, or Amazon, etc., which encourage you to follow a link in that email. The link might look like a link to the proper institution, but the actual address is to another site. For example, you might be sent to http://ebay.criminalscammer.com/ which has no association with ebay.com and will instead steal your eBay credentials if you type them into their bogus site. The fake link can be very insidious where it uses some wacky foreign alphabet character that makes the link look like the right web site, something like bankøfamerica.com. You might notice the slash through the "o", but there are other character substitutions where there is no visible difference.

This brings us to the first two rules of Internet safety:

Rule 1: Don't trust a link that you get in email, no matter who it says it's from. Especially don't trust it if it takes you to a bank or commerce web site. Even links to non-commerce sites can be malicious, since there are flaws in browsers that allow a malicious web site to take over your computer, but that's a whole different topic. So, if your best friend in the whole world emails you a link to the funniest photo ever, and you just have to see it, be skeptical and consider verifying the source of the link before clicking it.

Rule 2: Whenever you are about to type anything into a web page that you wouldn't want posted on the bulletin board at the local prison, make sure the link starts with "https://" and that your browser is showing you the lock icon.

That's where we were until early 2008. As long as you always typed in your web addresses, or used bookmarks you created from web addresses you typed in, and you looked for the https:// and the little lock, you were safe.

Then last year, Dan Kaminsky found a problem, but first I have to explain another vulnerability.

There's a step in the web communication process that can be subverted. When you type https://www.yourbank.com/ into your address bar, your browser has to do something like looking up a phone number. Computers on the Internet aren't addressed by name, but instead by a number called an IP address. It's like when you place a phone call, you don't type in someone's name, you enter their phone number. There are special servers on the Internet, called DNS servers, that perform that lookup. So, when you type https://www.yourbank.com/ into the address bar, your computer connects to a DNS server and asks for the correct IP address. That process can be subverted. It's been known for a long time that it's easy to do this locally. So, if you're using the WiFi connection at your local coffee shop, some criminal might also be sipping coffee there and sending your computer fake DNS responses that will send you to their evil server instead of your bank's server.

Rule 3: Don't trust web pages when you're surfing from a public access point. This includes free WiFi at coffee shops and libraries, and also wired Internet connections at hotels, Internet cafes, etc.

That used to be a good rule, until Dan Kaminsky pointed out a problem in the DNS system that has been there for years. There was a flaw in the programming used by DNS servers that made it possible for the bad guys to attack the server and trick it into sending our false information. So, even if you typed in https://www.yourbank.com/, the real DNS server might send you a bogus response that would send your browser to a criminal web server. This is a very bad problem as nearly all of the millions of DNS servers out there were vulnerable. Dan worked closely with the folks who control the majority of the DNS servers to get the flaw fixed on as many servers as possible before announcing the problem to the world.

The careful reader might be thinking that even if someone fakes your DNS responses and sends you to the wrong site when you're trying to do your banking, the https:// and the little lock means that you are connected to the real bank site and your information is encrypted so it can't be read even if it's intercepted. That was true until...

Getting Valid Certificates for Fake Sites

This year at DEFCON, Dan Kaminsky announced another flaw in a major system behind the safe operation of the Internet: it's possible for the bad guys to trick browsers into thinking they have valid certificates for sites they don't own. Certificates are the mathemagical basis of how your browser's little lock icon determines that it's safe to enter and send your private information securely to the party you intend and no one else. The certificate does two things: it proves to your browser that the site it's talking to is the real site for the address in your address bar (which is why it's critical that you have the correct address in your address bar) and it gives your browser the means to establish a secure communication channel to that server which can't be read by anyone else even if they intercept all of your transmitted data. It is widely believed that this security cannot be broken even with a lifetime of effort by an army of supercomputers. And that's still the case, except: the bad guys can get real certificates that allow them to impersonate secure sites.

The trick is somewhat technical, but it is fixable. Hopefully, this flaw will be taken as seriously as the DNS issue was and the several contributing flaws will all get fixed soon. If you're not interested in the technical details of the flaw, you can skip the next paragraph.

When you apply for a certificate from one of the many certificate authorities, you submit a document that states what domain name you want secured. There are multiple formats for encoding this string, including preceding length byte and zero-byte terminated. If you combine both, evil ensues. For example, you can submit a form using the length-byte format for the domain [37]www.yourbank.com[0].criminalscammer.com where [37] represents the length byte covering the entire string and [0] represents a zero byte in the middle of the string. Some certificate authorities will parse this string, pay attention of the length byte, but recognize that the zero-byte isn't a valid character (the digit '0' is not represented by a zero-value byte in order to avoid confusion when using zero-byte terminated strings, see info on ASCII encoding) and parse the string as www.yourbank.com\x00.criminalscammer.com. Their computer decides this is a perfectly reasonable request and contacts the owner of the criminalscammer.com domain to make sure the request came from them. The criminal scammer validates the request and the certificate is granted. The problem comes when a browser gets a bogus DNS reply for www.yourbank.com which directs it to contact the evil server with the wacky certificate. When the browser encounters the zero-byte, it may interpret the wacky domain name differently than the certificate authority and treat that zero-byte as the end of the string and decide the certificate is for www.yourbank.com.

Once this is set up, the victim submits banking info to the evil server and now the bad guys can log into the user's bank account. That's a bad thing.

The good news is that for this to be a problem two things have to occur. First, the user has to get directed to a fake site through a bogus DNS reply, and second the browser has to have the flaw that allows it to see the phony certificate as valid for the legitimate site. Which brings us to:

Rule 4: There is no rule four, follow rules 1 through 3 to avoid getting sent to a counterfeit web site.

We hope that certificate authorities will stop granting these zero-byte certificate requests and browser vendors will fix their code that interprets these fraudulent certificates.

Colleges Throw Out Students' Internet Privacy, Expose to Fraud

Endgrain, an observant student at the University of Southern Maine noticed something odd when he entered a chat room after logging into the university's network: people in the chat room started addressing him by his full name. He did some sleuthing and found out how his university was broadcasting his full name to everyone on the Internet.

When a student at USM logs into the network for the first time, they have to enter their username and password. The network then remembers that machine (by its MAC address) and thereafter lets the user onto the network without entering credentials. It also assigns that student an fully Internet accessible IP address, and maps that IP address to a domain name that includes the student's first and last name. There are a number of problems with this scheme.

First, because the IP address is publically available on the Internet, with no intervening router or firewall, the student computers are open to direct outside attack from anywhere on the Internet.

Second, because the IP address has a full DNS name revealing the student's name, the student is fully exposed to all sorts of privacy attacks. Every web site they visit logs those visits, and hence logs the student's name. Likewise, Google searches are logged and thus a student's search history is exposed to the world. Many other Internet activities expose students to a loss of privacy.

USM isn't the only school doing this to students, at least the practice of assigning DNS names that include each student's full name. According to research done by Endgrain and Dan Kaminsky, some 60 universities are doing this.

Presumably, this destruction of student privacy is done to streamline RIAA lawsuits against students pirating music. With the DNS clearly revealing a student's name, university, and even approximate location on campus, the RIAA can serve up lawsuits without having to go through the bother of getting a court order to find out who is behind an IP address identified as illegally sharing music.

The worst part of this whole thing, at least as USM has implemented it, is that it actually hurts the ability of the RIAA to identify who's behind an IP address. Anyone on the university network can watch traffic and determine which MAC addresses belong to which students. It's then trivial for a malicious student to spoof another student's MAC address then do bad things masked by the DNS name pointing to an innocent student all without ever learning that student's network password. Because of this flaw in how USM allows unsecured logins by MAC address, any student who gets sued by the RIAA has an easy defense: it's wasn't me, someone must have spoofed my MAC address. Guilty students get an easy defense, and innocent students are left to defend themselves in court because of a flawed system.

Everyone loses here. Students lose their anonymity on the Internet and can be identified by anyone, with no need for having a good reason to identify a user or obtain a warrant or court order. The RIAA, and other intellectual property owners, can't actually use the DNS names to identify students since the system is so easy to subvert. Universities look like spineless dorks for outing their students and exposing them to computer attacks.

Students who go to universities that are doing this to their student body should be raising the alarm and forcing a change in policy. We don't want our universities to be teaching students that they have to abandon their first amendment rights for the illusion of corporate convenience.