Hacker News Reader

Comment by patio11 | Hacker News Reader

This situation is virtually made for client-side certificates:

1) You won't need passwords beyond whatever it takes to log in locally.

2) You can assume the hospital computers are physically secured. (Well, I wouldn't, but apparently they do.)

3) The hospital changes machines very infrequently and probably wants a human in the loop every time a machine changes.

4) You can have certificate generation and registration get handled by the on-site IT staff. It is once in a blue moon, and makes them feel like they're not getting paid 6 figures to clear paper jams and reboot Windows.

5) You can mumble any sort of cryptographic magic to scare away people who know just enough about security to be dangerous.

View on HN

There is one problem with this - now that you've deployed client side certs you now have to implement a software distribution product just to deploy certs to the 100's of computer that require them... or, in this article case, the single computer) :)

Systems Management vendors love to sell software distribution products to help reduce the distribution requirements for client side certs, but in the end most folks will balk at the price and end up resorting to the sneaker-net approach.

Wouldn't you be able to do this via Active Directory group policy?

That's the route I would have gone, just write some tiny local web app which authenticates against AD and then redirects to the external service.

I don't know why they wanted to go ip-based or even bother with cookies since AD queries are practically free.

In ASP.net with all the builtin integrations for AD that's a one day project.

Ahh yes, the expensive deployment options. Too true. You can use Admin Arsenal. (www.AdminArsenal.com). It has a 30-day fully functional trial so as a one-time option you can do the cert deployment at no cost. Plus, Admin Arsenal doesn't use agents and is installed on your workstation, so it doesn't require its own server.

If you want to keep it the licensing is simple - per administrator, regardless of the number of systems that you manage.

Check it out.

I really would love to use client-side certificates everywhere. It's just too much of a pain in the ass to do so.

Off the top of my head: - Generating client-side certificates is expensive or a pain in the ass. - Every browser deals with client-side certificates differently. Some give scary warnings, etc. - Firefox and IE can generate keys locally and send a CSR to you, but they do it differently. Safari can't even generate keys locally.

I really wish that the state of client-side certificates was better than it is. I look forward to the day when I can easily build services that use client-side certificates.

It's not hard to generate a certificate request. While Firefox and IE may use different routines to do a local key generation, it's certainly not difficult.

The scary warnings you're talking about come up if you're connecting to an "untrusted" site - who's SSL server certificate isn't signed by a known, trusted root CA.

It's certainly the best solution to this problem.

Yes, generating a certificate request isn't hard. Maintaining a CA is annoying at best.

Do you have a link to a site that describes how to do local key generation in Firefox and IE? Maybe I was just looking in the wrong places?

The scary warnings I was talking about are not the "untrusted" site warnings, they are the warnings you get after the remote SSL server times out. I guess this can happen after a few hours, depending on the server.

Yes, it's the best solution to this problem, but it's still a major pain in the ass.

I came here to post just this. 2-way SSL is perfect for this scenario, and a hundred times more secure than any of the alternatives.

Reply on news.ycombinator.com