Re: [Discuss] free SSL certs from the EFF
Edward Ned Harvey (blu) wrote: >Tom Metro wrote: >> ...if the host name even sounds like a site that might sell things >> (e-commerce), they won't issue a cert. > > Huh? I use them for numerous companies, including e-commerce. > Where'd you hear that? Directly from them when I applied for a cert. Here: https://www.startssl.com/?app=39 It says: The StartSSL Free (Class 1) digital certificates...provide modest assurances and are meant to secure personal web sites, public forums or web mail. And when I applied for a cert for a domain with "shop" in the name, even though it had no e-commerce, they rejected it with: Thank you for requesting a digital certificate with us. However Class 1 certificates are not meant to be used for commercial activities or financial transactions according to our policy. For this purpose please consider upgrading to Class 2 or higher verification level. They're documentation could state this limitation more clearly. I explained to them the site had nothing to do with financial transactions, to which they responded: Unfortunately we can't control for which exact purpose you are/will be using the certificates. The rejection has been triggered by the 'shop' key word at your domain which is not allowed at Class 1 Free certificates. Financial institutions and e-commerce web sites must upgrade to a validated level. Thank you for your understanding. So basically if you sound like a store, you're out of luck. If you don't sound like a store, you can use the cert for whatever you want. Automation at its finest. (Not sure why they bother to have humans sending out and responding to the notices if they aren't empowered to override the automation.) > if I've been accidentally slipping through the cracks all these > years. Yes, you have. >> But EFF isn't stopping with merely making the certs free. You still >> have to jump though a few hoops with StartCom, and it sounds like >> EFF wants to add more automation to the issuing process to make it >> faster/trivial to add SSL to a site. > > I think when you say you have to jump through a few hoops with > startssl, you just mean you have to receive the validation email(s) > and either figure out how to generate your own CSR, or trust them to > generate the private key for you. And then you download the cert and > install it into apache (or whatever.) Yes. Plus pretty much every cert I've requested from StartCom has prompted one of their support people to email requesting additional identifying information. > Whereas these guys have the tool that basically automates all that > process. Yes. > They say it takes 1-3 hours. For me, it takes about 10 minutes, but > maybe I'm just good at it. 10 minutes seems perfectly realistic if you are already familiar with the procedure, have already set up an account with the CA, and are already familiar with the installation procedure on your web server. Provision a cert from Comodo through Dreamhost's panel, and the process similarly takes only about 10 minutes due to their automation and hand-holding. > They say their goal is 15-30 seconds, which is unrealistic. Probably. That apparently excludes setting up an account at the CA (which I'm guessing is still necessary) and installing their tool on your web server. As you observed, they seem to be leaving out some setup overhead. > (Side note) Historically, I've always thought, you need to generate > your own CSR in order to keep your private key private. But more > recently I'm thinking, This is the CA we're talking about. So what > if they have the private key. If they're going to attack you, you're > screwed even if they don't have the private key - because they can > perform a validated MITM attack, which is only a little more hassle > for them. (End Side Note) True. Unless the client is taking extra steps to detect a cert change, and even then who would suspect a new cert from the same CA as the original one they fingerprinted? However, if the CA is sloppier about handling your private keys than they are about securing your own, it potentially expands your attack surface. For example, your private key might reside on one of the CA's web servers as they process your request, even if the actual signing happens on a more secured back-end machine. That web server could get compromised, leaking your private key to a third party. > It looks like the main value they're talking about in that article is > the ACME automated process for identity validation (... and automated > installation). I wonder if existing CA's like startssl would be > unable to easily adopt a new automated process like that, because of > the fact that they're a CA they must stick to their existing > documented processes. I would assume that if StartCom sees this new effort as adhering to the same philosophy that led them to offer free certs themselves, that they'd adopt the protocol to make their service equally easy to use. What's
Re: [Discuss] free SSL certs from the EFF
> From: discuss-bounces+blu=nedharvey@blu.org [mailto:discuss- > bounces+blu=nedharvey@blu.org] On Behalf Of Tom Metro > > We sort of already have this today with StartCom (StartSSL), but they > have limitations on their free offering. No wildcard certs, and if the > host name even sounds like a site that might sell things (e-commerce), > they won't issue a cert. Huh? I use them for numerous companies, including e-commerce. Where'd you hear that? I'd like to know if it's completely bunk, or if I've been accidentally slipping through the cracks all these years. > But EFF isn't stopping with merely making the certs free. You still have > to jump though a few hoops with StartCom, and it sounds like EFF wants > to add more automation to the issuing process to make it faster/trivial > to add SSL to a site. I think when you say you have to jump through a few hoops with startssl, you just mean you have to receive the validation email(s) and either figure out how to generate your own CSR, or trust them to generate the private key for you. And then you download the cert and install it into apache (or whatever.) Whereas these guys have the tool that basically automates all that process. They say it takes 1-3 hours. For me, it takes about 10 minutes, but maybe I'm just good at it. They say their goal is 15-30 seconds, which is unrealistic. Notice they didn't prompt for the name, locality, unit, country, or anything? Didn't prompt to accept usage terms. You can't even enter that stuff in 15-30 seconds. They show people puzzling over openssl commands, not clicking the "generate CSR for me" button on the CA's website. Don't get me wrong - it looks cool - but they are overselling it, deceptively. (Side note) Historically, I've always thought, you need to generate your own CSR in order to keep your private key private. But more recently I'm thinking, This is the CA we're talking about. So what if they have the private key. If they're going to attack you, you're screwed even if they don't have the private key - because they can perform a validated MITM attack, which is only a little more hassle for them. (End Side Note) It looks like the main value they're talking about in that article is the ACME automated process for identity validation (... and automated installation). I wonder if existing CA's like startssl would be unable to easily adopt a new automated process like that, because of the fact that they're a CA they must stick to their existing documented processes. I'm also going to say - These EFF guys are a "new CA" which means they're going to face the same problem that startssl faced in terms of adoption. Sure, everybody including Honest Achmed can become a CA for Mozilla and Apple, which will take effect almost immediately. And getting into Microsoft might not even be that difficult - But the only way the new CA becomes globally trusted is for all the clients to receive updates afterward, and you know how good people are about updating everything... The majority of users, on every platform, resist updates. Wait to see what people say about the new iOS before applying... Refuse to update OSX because OSX can't get viruses *sic*. Android, barely ever updated. Even windows, which IMHO does the best job of nagging the users, very often fails to get updated... (If you haven't seen it before, read about Honest Achmed: https://bugzilla.mozilla.org/show_bug.cgi?id=647959 Slightly racist, but not intentionally, and makes a good point.) ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
[Discuss] [Position-available] Harvard Medical School Job Post: HPCC Storage Engineer
--- To post your own position-available or position-wanted message, please follow the procedure at: http://blu.wikispaces.com/job+posting+policy --- Harvard Medical School Infrastructure Operations (IOPS) and Research Computing teams seek a HPCC Storage Engineer with strong experience in parallel file systems and high performance computing (HPC) in support of our world class Research. Help us design implement and manage cutting edge data storage and management systems in our HPC environment. The successful candidate will work closely with both the Infrastructure and Research Computing teams as well as our diverse user community. The HPCC Storage Engineer position is full time, salaried. Successful candidates will have demonstrated experience with parallel file systems (Lustre, GPFS, etc) and HPC. We expect you to have a high level skill with hands-on experience of complex storage and computing architecture. You will be eager to take on new challenges and help design systems to support and manage massive amounts of mission critical data. You are highly self-motivated and eager to be part of a high performing committed team of IT professionals. Duties & Responsibilities: • Hardware deployment, configuration, maintenance, repairs, service-related issues. • Configuration Management with; Ansible, Chef, Puppet, SALT or similar. • Set up and troubleshooting node network connections. • Management of shared network folders/volumes • Advanced troubleshooting to completion and resolution, including vendor escalation when necessary. • Management of the HPCC and storage infrastructure • Management and utilization of hardware and software monitoring systems. • Software patch management • Hardware and software lifecycle management. • Design and planning for expansion and future growth. • Participating in user groups for 360-degree feedback, clientele feedback, and issue resolution. • Provide detailed documentation related to HPCC and storage systems. • Participate in a 24x7 on-call rotation. • This position will require occasional night and weekend work. Basic Qualifications: Bachelor’s degree, or equivalent professional experience. Seven plus years of IT experience with a minimum of 5 years in HPC/Storage Engineer positions with direct interaction with servers and hardware. Apply Online: http://hmsiops.it/hpccstoreng2 ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] Revisiting VMWare ESX backup options
On 11/19/2014 1:40 PM, Rich Braun wrote: And another reason for my head being in the clouds on this one (yeah, I love that Cloud buzzword): getting in the daily habit of something the business world's already doing Go jump off a cliff. Everyone else is doing it; why haven't you? :) Because jumping on the bandwagon for the sake of jumping on the bandwagon is foolishness. Do things because they are appropriate solutions to the problems being solved, not because they're the flavor of the week. That's not being closed-minded about new technologies and ideas and ways of doing things; it's ensuring that my customers get the best solutions to their problems. -- Rich P. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] Revisiting VMWare ESX backup options
Richard Pieri notes my head-in-clouds idealism: > It isn't an idealistic "encrypt > everything and the world will be better" philosophy. It's a specific > reason to take specific action. That is, it's a specific threat And another reason for my head being in the clouds on this one (yeah, I love that Cloud buzzword): getting in the daily habit of something the business world's already doing makes the same sense to me as switching from subversion to git, setting up multi-factor authentication, or (as I'm doing now) learning to code in python instead of ruby or php before that or perl or... Why not embrace these technologies before one's old habits become obsolete, and gradually limit career options? -rich ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] free SSL certs from the EFF
On Wed, Nov 19, 2014 at 11:34:19AM -0500, Richard Pieri wrote: > On 11/19/2014 2:34 AM, Tom Metro wrote: > >All the automation does make you wonder whether it is going to be easier > >to game the system. > > I don't wonder. Each automated step in a process is an avenue for > bad actors to abuse the process. NB: automation includes human > workers following a script. I would amend that last statement to say "MAY include"--I certainly have had my share of involvement with procedures read from scripts, where the people following them used their brains to make intelligent decisions with vastly varying degrees of success. Some are quite excellent. The trouble is those people are usually recognized as such and promoted to positions where using their brains provides more value. This is right and good... at least for them. It does not bode so well for you. -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] free SSL certs from the EFF
On 11/19/2014 2:34 AM, Tom Metro wrote: All the automation does make you wonder whether it is going to be easier to game the system. I don't wonder. Each automated step in a process is an avenue for bad actors to abuse the process. NB: automation includes human workers following a script. -- Rich P. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
