Slashdot videos: Now with more Slashdot!

View

Discuss

Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

wiedzmin writes "Anybody who has worked around anything dubbed an 'appliance' in the past few years knows that they come with a management Web interface, which is usually 'secure.' However, no company in their right (accounting) mind will spend $400/year per appliance to buy Verisign SSL certificates to secure Web interfaces on networks that may not even be open to the public Internet. So network administrators, and sometimes end users, are stuck clicking away at an annoying 'Continue to this website (not recommended)' message every time they connect, setting an unhealthy precedent when it comes to the actual security of SSL and the much-hyped MITM attacks. So the question I have for the Slashdot crowd is: do you have valid SSL certificates on your intranet sites, and if so what do you use? Any cost-neutral, or at least cost-conscious solutions out there that don't involve manually distributing your certificates and CRL to every workstation in the company? Thanks."

Why not set up a private certificate authority? Then you can manufacture as many SSL certificates as you need for private use and all you need to do is distribute the certificate authority's certificate to each browser once for the entire enterprise. Every browser out there has a way to add additional trusted certificate authorities. Indeed, if you have a "centrally controlled" provisioning system, you can even add the certificate to your default system build. Then the scary warnings go away completely.

Sorry, but every certificate authority is manually distributed at some point, the verizon's of this planet included, they just have the convenience that browser manufacturers do that for them.

The most automatic way to do what the main requester wants is to set up that certificate authority and roll out your browsers automatically after adding that certificate authority it's root to that browser.

AD's set of default group policy templates only makes it trivial for IE; but you can also impose login, logoff, startup, shutdown, and a bunch of other locations for running arbitrary scripts/programs.

Most browsers, and any other programs that have SSL-related business, either store their set of trusted certs/authorities as a set of certificate files in some reasonably easily discoverable directory or piggyback IE's settings. If the former, you just execute a trivial file-copy script via group policy any

Yes! I've discovered lately when evaluating Chrome for workstation use that Chrome now has a (ever-growing) list of group policies available. Grab the adm/admx [chromium.org] templates and MSI installer and check them out.

Coincidentally, the latest Chromium/Chrome Canary/Chrome Dev builds also started ignoring IE's trusted zone lists and so windows integrated authentication (Kerberos Negotiate) stopped working. Boo. Supposedly there's a new policy that I can set to fix this. I reported the issue [google.com] but am waiting for clarifi

Sorry, but every certificate authority is manually distributed at some point, the verizon's of this planet included, they just have the convenience that browser manufacturers do that for them.

And there's the big difference.

The most automatic way to do what the main requester wants is to set up that certificate authority and roll out your browsers automatically after adding that certificate authority it's root to that browser.

Apparently some sites sell rapidssl wildcard certs for cheap. I can't remember which ones. Can't find them via Rapidssl's own website for some reason;).

You have to understand the truth of the matter. Most people dealing with https don't really care that much about security. All they want is not to have those scary browser warnings.

If they really cared about security they would realize that most popular browsers by default do not warn you if a site's CA has changed, or a server cert has changed rather prematurely (I use certificate patrol for that). And that as long as this remains true, all the talk about https security is just talk.

So people should just solve the submitters problem, and implying he's incompetent or even calling him incompetent. Because how many of you are relying on https to keep stuff safe and have CA certs in your browser from CA's you do not trust?

FTFP: "Any cost-neutral, or at least cost-conscious solutions out there that don't involve manually distributing your certificates and CRL to every workstation in the company? Thanks."
Before snarking on the FP author, perhaps you should actually read the FP's question?

So a login script (or in a Microsoft environment, an AD group policy) that distributes the certificate automatically to each computer meets your definition of "manual distribution?"
Really? That's what you're saying? "Automatic" and "manual" are synonyms in your universe? wow.

that don't involve manually distributing your certificates and CRL to every workstation in the company

So automate the distribution. Logon script, group policy, OS update patch, software distribution push out, whatever. You do it once and it's done. Then put it on your standard image and never worry about it again.

We don't manually distribute certificates or CRLs here. Software distribution for all other purposes also serves that one.

Being snarky and encouraging the poster to indulge in a more fully-featured systems management environment is appropriate here. If you want to leave the porch, you'll have to run like a big dog... Otherwise, stay home.

Remotely update large numbers of workstations without having to sit at every desk in the company is just one of those things that sysadmins do. If you can't do that then you should focus on learning how to do it first and worry about how SSL certificates work later.

It's impolite, but the truth. If your job entails running a company's computer systems, you should already know (or be able to Google) the fact that you either have to pony up for SSL certs or generate and distribute your own. There is no in between. In systems administration, the question of "how do we solve this?" is almost always answered by "rolling our own" or "paying someone".

I knew nothing about certificate's, certificate authorities, certificate servers and running your own private certificate authority, but I was curious.. (This was as I read the original question, before the comments) so I went to wikipedia and spent about 2 minutes reading about SSL certificates until I started reading http://en.wikipedia.org/wiki/Certificate_server [wikipedia.org], and noticed the Open Source Implementations part...

When did asking a question cease to be a valid method of finding things out?

I mean, it's great that you can find information like this from Google or Wikipedia, but it can be a risky strategy, and you might end up following a howto that results in a non-optimal implementation, or lacks crucial information, or doesn't adequately detail the pitfalls of a particular method. Or maybe you're like me, and sometimes you just can't think of the right search terms to use.

The available certificate servers which are Free Software tend to be rather user-unfriendly. Maintaining certificate revocation lists and handling certificates for different purposes (mail, web, code, client authentication, vpn...) are needlessly time-consuming chores. Obviously any competent system administrator can script their way out of it, but in this case it is a rather large effort.

Thanks for the links, very informative. I have the same basic question as the submitter but with a slight variation: Do the certs get installed on the computer or printer if you want to make the https web management feature not give you that warning?

Indeed. An "enterprise PKI," as Microsoft likes to call it, handily solves this issue. Just add the root CA and intermediate CA certificates to the computers via Group Policy -- just as you would if you needed to trust a novel CA (such as, for instance, the DoD CAs). As an added bonus, if you activate auto-enrollment on Windows, your users get access to encrypted and signed e-mail, and you can trivially kick PPTP VPNs to the curb and use IKEv2 or L2TP instead. With a little more work, you can even get IPSec

Not only that, but if you're don't feel like using using the OpenSSL command line, you could always use a GUI front-end like TinyCA [sm-zone.net] to make life easier. On Ubuntu, it's available prepackaged.

And to those of you here who claim "half a brain": please remember that you yourselves may someday need to do something (legal, financial, educational, even technical) for which you are less than half competent. Yes, you have achieved a "win" in humilating a sincere poster, but it's the cheap victory enjoyed only by the pusillanimous.

Here's the deal. Either this person is administering a smallish number of machines, in which case he/she can simply go 'round and install certificates on all of them, or they're administering an assload of them, in which case they do indeed deserve the scorn for not being willing to do a modicum of research and choose the standard approach.

Your defense only works if they're in charge of too many machines to administer manually, but yet have no experience doing so - a situation which is highly unlikely. It

I use StartSSL for tens of certificates on all manner of internet and intranet sites.
I had to install their root certificate on Windows 2000, but any computer that gets regular windows updates should have had it since last year.

They don't charge for certificates, they charge for work a person has to do: verifications.
Meaning, if they have to call you, it will cost, but you can get regular certificates for free.

I use StartSSL for tens of certificates on all manner of internet and intranet sites.
I had to install their root certificate on Windows 2000, but any computer that gets regular windows updates should have had it since last year.

I'll jump on the StartSSL praise train, too. For $50/year, you get unlimited SSL certs for any domain you control, or personal authentication certs (i.e., e-mail) for any e-mail address you control. The certs can include wildcarding, multiple domains per cert, and lots of other features that other CAs charge an arm and a leg for.

I noticed that I had to install their CA cert when I was using their completely free certs, but their class 2 certs were issued by a different CA that was already in IE and Firefo

Again, another fan of StartSSL. User of both server certs and client certs for personal and business use. Their cost model is much more inline with reality than Verisign or the others... Plus, EV certs if you need them.

Every browser has a way to store the security exceptions so that you don't get that warning every time. Just set the box up on a private network the first time to avoid a MitM attack and store the cert. If you ever get another warning about an untrusted cert from the box, then you might have a MitM attack going on, but otherwise if the cert matches you're fine.

You could also set up your own local root authority (most larger companies do this) and make your own certs.

Check the name on the cert. if it is self signed, then you just have to deal with it. But if it is root signed, look at the site name. If you can find a way to use that site address to access the device then you will not get prompted.

My home router has a valid cert, but I would use the ip address and get prompted every time. I ended up making an entry in my host file for "linksys" at that address. Now when I go to https://linksys/ [linksys] everything is ok.

I don't know about your corporate policies, but if the main IT department doesn't want to deal with it, you could set up your own root cert for your department and just use that. Presumably you have a bit of internal server space somewhere that you could host it on. They're not really that hard to set up, there are a lot of tutorial online that will help you.

I do not see "startssl" listed in the list of built-in root certificates under Firefox.

Does this mean that if third-party users access my web site, they will be "stopped" with the typical warning that the site is secured with an unknown certificate - and make them go through the ususal steps to add it, etc?

Or will it just "work". Will they get the nice colored emblum on the address bar saying "Verified by: startssl", etc?

In otherwords - will it be any better, or more transparent to the user than they

If by "nice colored emblem", you mean the blue indicator next to the address bar and the padlock icon in the bottom-right, yes. It works fine. No scary warnings or anything. Such standard SSL certificates are fully trusted by Firefox, and are free of charge.

If, however, you mean the green Extended Validation indicator next to the address bar, this also works fine, but costs a bit of money. Not a big deal.

http://lmgtfy.com/?q=how+to+set+up+a+certificate+authority [lmgtfy.com]
Then distribute the *organization's* cert to all the servers and clients. If you have a few clients or don't get many that fast, just do it by hand. If you have hundreds of computers or lots of turnover, you should be running central config management anyway.
MIT for example distributes an MIT cert. Presto, everything on campus is protected. It's partially a question of tradeoffs: sign a cert by a CA already trusted for $$, or make your own CA

For a private (e.g., not ecommerce, banking, etc.) web site, just create a certificate authority and use self-signed certificates, and send an email to the users covering the installation of private certs in MSIE, Firefox, Chrome and Safari. Don't waste your money on a versign cert because all it does is eliminate the warning for a price, whereas your users can eliminate it for free. Why add the tracking of additional "licensing" fees to your workload?

... just create a certificate authority and use self-signed certificates, and send an email to the users covering the installation of private certs in MSIE, Firefox, Chrome and Safari. Don't waste your money on a versign cert because all it does is eliminate the warning for a price, whereas your users can eliminate it for free.

Seriously? Let's assume an organization with only 100 employees. If just 10% of them require help setting this up, at say 15 minutes user time lost buggering around, plus 15 minutes support from the helpdesk, then you've lost 4.5 hours of total productivity. That covers the cost of a wildcard cert for your internal domains for a year. (Maybe not from Verisign, but certainly from someplace sane.)

Of course, in the real world, at least half of the users won't bother installing the cert, leaving them vulner

Judging by plenty of the comments in threads similar to this, I think most of us are tired of seeing Ask Slashdot posts on how to do his or her job. Had this been really cutting edge, or new grounds, I could understand. However.. Enterprise PKI? Seriously? If this is to be the continuing trend of Ask Slashdot, I need to adjust my filters.. because that is just sad.

I'm finding more and more IT folks are standing around waiting to be spoon-fed solutions, instead of trying to research and educate themselves on what is already out there. It worries me that this is not just the trend in IT, but across all occupations. Am I just getting old and crotchety, or is this a new trend?

That's the "I'm feeling lucky" google-fed generation.If it's not on the first page in google results, go and ask in a forum.Though, that's actually old-school, sort-of - people tend to ask in their twitter feed nowadays...

Worse than crotchety.
You're chastising someone for using every method at their disposal to learn what they need to know, while telling them they need to go figure it out for themselves.
Your answer is akin to saying "I have enough time to answer you and yet I don't want to help you."
Do you advocate building your own car instead of taking public transit?

When you love what you do, you want to always learn more. I've worked IT for a small company and googled a lot. I winged a lot of the job using google.. but I didn't google for forums or quick answers. I would educate myself. I would teach myself using the wealth of resources available on the internet and find I'd be able to get anything done if I put my mind to it. For the few odds and e

Dozens of man-hours will now be spent explaining basics of inhouse certificate authorities and self-signing, along with comments on your lack of basic research, intelligence, qualification for your position, and legitimate parentage.

..that don't involve manually distributing your certificates and CRL to every workstation in the company?

Here's where you went wrong. If you insist on keeping this constraint at any cost, then you have lost. Pay that cost (you don't get to have intranet sites) instead of getting what you want, and accept that you got the lesser of two "evils" (from a very perverted point of view).

The main problem with looking at it that way, is that you (or someone) already did what you claim you want to avoid. Those wor

The biggest problem is in off-the-shelf appliances (like wifi routers) for the whole spectrum (from personal to enterprise); they don't have domain names, so you can't have an internal CA root blessing them (at least, not out of the box), and a non-enterprise location can't easily do that.

One solution could be to bundle a CA root into the router. Initial setup would involve picking an internal TLD (with a randomly generated suggestion so we don't have everybody using "home" or "linksys"), then the CA roo

First, $400 is a stupid price to pay for an SSL cert, many providers are much cheaper...

Some cert providers (Eg startcom) will provide unlimited certs under a particular domain, so assuming you use the same domain internally its quite easy to generate more certs for the same price you paid for your external certs.

On the other hand, if its internal to your network why don't you create an internal certificate authority and just ensure its root cert is trusted by all your devices.

Surfing without encryption opens you up to eavesdropping and spoofing.

Surfing with encryption protects you from eavesdropping and spoofing.

Surfing with a self-signed encryption protects you from eavesdropping, but not spoofing, since you don't know who the signer is.

Yet, Firefox treats self-signed certificates as if they were worse than no encryption at all. The default behavior should be to treat self-signed certificates as if there was no encryption at all (from a user perspective). To give users these di

If it's an enterprise using domains, set up your own CA and create your own CA signing certificate. Push that certificate out into the root certificate bundle or database for your browsers etc., and use it to sign all your server certificates. Since browsers can validate your server certificates, they won't complain. Have the certificate available for importing into browsers that don't accept automatic pushes. That should solve the problem, at least internally.

Most of my company intranet is plain http. There are two parts that we encrypt with SSL. First is the optional login widget on the intranet front page. Employees can customize their front page if they choose to login, but it's not required. But since we use a single sign-in type of situation, where many services are authenticating against the same LDAP service, we feel like we should keep that password encrypted, even on pages not available to the outside world.

I've seen similar comments get marked troll before. Yet for many websites, the direction of trust is from them to you. If you want to log in to my website, which provides information, I store no personal information other than a user name and password. I have to trust you before giving you the information you want.

What we actually have here is a psychological issue - the cert vendors want you to believe that anyone who doesn't buy their certs is a potential criminal. The rule should simply be "no financial

I don't believe so BUT what they are selling is a certain lack of online anonymity. If the person they sold the cert to IS a crook then you now know where to find them.

Anyway... my favorite thing to talk about these days: Being that I work for a company in the business of selling security you get a pretty clear picture very fast that all security is a false sense of security. At that point you can either go hide yourself in a bunker somewhere in your tin-foil hat OR you can come to terms. Given my choice

There absolutely needs to be some kind of warning for untrusted certs. I can see an argument that the current solution is overkill (I disagree), but treating it the same as an HTTP page gives users no easy way to check whether or not they should trust the connection.

Now, I'm of the opinion that browsers handle untrusted certs as well as they can with current technology. Time and time again, end users have shown that they'll click through simple warning dialogs and send their data to phishers. When a server

Time and time again, end users have shown that they'll click through simple warning dialogs and send their data to phishers. When a server establishes an HTTPS connection with a client, it's telling the browser that this should be a secure communication, and sensitive data is going to be transmitted. If the browser can't validate that the connection is trusted, the user needs to know something is wrong.

That browser behavior is what needs to change. When accessing a site with an untrusted cert, the browser should act like it would with a plain HTTP connection. No padlock, no blue/green address bar, no indication of enhanced security, but no warning - maybe it could show a status bar icon, a padlock with an exclamation mark or something, as a little unobtrusive indication that the certificate is untrusted, but it shouldn't interfere with the browsing experience by stopping the page from loading and displayi

Browsers should treat untrusted certs the same as unencrypted pages - they're at least as secure [as unencrypted pages], possibly more secure than "trusted" certs (such as me connecting to my home server with a self-signed cert, I can be certain no third parties, even governments, could illegally obtain the certificate and perform a MITM).

This is done by having the server present a certificate, which the client can then verify was signed by one of many trusted authorities.

The only thing the "trusted authorites" confirm is that the person who has the cert paid for it.

Some trust.

The whole SSL certificate crap is a scam. The only interesting thing to know would be "is this site using the same certificate as the last time I connected to it". And the shitty browsers don't tell you that.

(The protocol should also have some reasonable way of doing rollover, like presenting a new certificate in the session "this is what we're going to be using starting...").

That is why SSL authenticates the remote site. Encrypting the transport prevents eavesdropping, while authenticating the remote site prevents man-in-the-middle attacks. You need both to have any degree of security.

But they don't authenticate the remote site. They just check that the remote site has a certificate signed by one of those super trustworthy people like Verisign or the government of China.