The way NOT to write HTTPS server

michen — Fri, 05 Dec 2008 10:28:00 GMT

Note: posted under rant tag, so you are warned ;)

I've just got a new wi-fi router, DIR-655 from DLink. Seems like a nice router, but at least one feature is just plain horrible broken. And it is security feature, which makes me wonder how secure the rest of the code is.

The router can be accessed and managed using HTTP server, like most any other one. It also has an option to enable HTTPS server, which was probably supposed to make management more secure. This is not very important if you connect from local network, but very important if you do remote management from the internet.

So I decided to enable it and connect using HTTPS. Internet explorer immediately complained that there are problems with certificate and advised me against proceeding :). IE warned me that (1) the certificate cannot be validated, (2) the certificate has expired, and (3) the certificate was issued to incorrect site. I proceeded nevertheless, checked the certificate, and indeed - it is self-signed, expired in September 2008, and issued to site www.dlink.com, which is obviously different from 192.168.0.1 :). Worse, I asked other guys with same router to compare certificate hash - it turned out all the routers are shipped with the same certificate!

I can understand the self-signing nature of the certificate - obviously DLink cannot put real certificate to the router. But why has it expired, shared by all routers, and most bizzar - why it indicates www.dlink.com as site name?

They could have easily generated an individual certificate for each router, issued to correct internal IP address for internal-facing server and to DynDNS name for internet-facing server. It does not add any hardware cost; the software could just generate a random self-signed certificate the very first time the router boots with a new configuration. User could then configure his browser to trust this particular certificate, and know he connects to his own router, not any of the thousands other routers with same certificate.

The way they did this feature, it is totally broken and makes no sense at all.

VALVe/Steam horrors

michen — Sat, 24 Nov 2007 02:20:00 GMT

(Update: VALVe has removed the worst recommendations that I described below. I don't know if my article had any influence on this. They still want to run the Steam as a service though).

I originally planned to use this blog for work-related stuff only, but the VALVe drove me mad, so I decided to write this.

I run Vista on my home PC (and at work too, actually), and all of us run as non-admins (not Vista's protected admin, but real non-admin). My son plays Counter Strike, and thus has to run Steam. It worked mostly fine, until recently it started to ask to install Steam as a service. Well, a service for internet-facing software seems not good. Before installing, I decided to find out more about it, and the finding are much worse than I've ever expected. Here is an official FAQ from VALVe that I've found:

http://support.steampowered.com/cgi-bin/steampowered.cfg/php/enduser/std_adp.php?p_faqid=460

Here are some of the recommendations from this FAQ:

Go to: Start > Run and type in: cmd

Type in the following:
net localgroup Administrators /add Local service

Restart your computer.

To put it simply, they ask to add Local service account to Administrators group! Apparently, they did not bother to find out the list of specific permissions they need, but simply figured out that administrator permissions "fix" the problem. That alone would be pretty bad, but they did even worse. Instead of creating special account for Steam or using some account that already has administrative permissions, they want to add account shared by multiple services to Administrators group, thus making not only their service, but all the services running on the machine much more dangerous and less secure.

Then VALVe gives even stranger recommendation:

If during this process you receive the error: System error 5 has occurred. Access is denied Please follow these instructions and then try the above steps again:

Go to Start > Control Panel > System & Maintenance > Administrative Tools > Local Security Policy.

In the left pane, expand Local Policies > Security Options.

Double-click Network Security LAN Manager Authentication Level.

In the drop down list, change the default setting (NTLMv2 only) to Send LM & NTLM - use NTLMv2 session if negotiated.

Changing LanMan level for Vista Home users to completely unsecure level? Maybe I'm missing something, but I can't see any reason to do this. This setting affects authentication to remove computers (mostly affects NT domain, should be of no concern to internet game), it would not help one to avoid local Access Denied while performing the steps above. It is not only completely unsecure, but IMO it also does not make any sense at all.

So these guys
1) don't understand anything about security,
2) can't write software that does not require administrative privileges,
3) don't even try to use the specific minimum list of permissions,
4) ask user to make completely unreasonable and unsecure configuration changes to OS configuration, that affect not just Steam service, but the whole machine,
5) want to run network-facing service with admin rights.

Now would you trust the guys who are clueless about security, obviously can't write secure code, and apparently don't care about YOUR machine security at all, to run network-facing service with admin rights on your machine? I don't. I think I'll try stay away from them from now on.

P.S. As with everything else in this blog, this post represents my personal opinion, and does not represent the view of my employer.

Michael Entin's notebook : Rant

The way NOT to write HTTPS server

VALVe/Steam horrors