Broken Browsers Part Two
May 28, 2009 on 3:51 pm | In Musings, Promotions, Rants by Josh Jones | 51 Comments
A couple of weeks ago I posted Broken Browsers Part One, which I can only pray gave you ample preparation for today’s post, Broken Browsers Part Two!
The truth is, not that much is broken in browsers these days. They’ve been around 15 some years now, so it’s not the biggest surprise all the major to be resolved by now.
In fact, I’d say the reason these two broken behaviors of modern web browsers still exist is because most still (and as I’ll try to convince you, erroneously) consider them features!
The browser should just listen to the caching info sent by the server!
Agreed… WHEN REQUESTING CONTENT FROM THE SERVER!
The fact is, pressing back or forward shouldn’t even request content from the server at all!
As one commenter brought up last week, whatever happened to “offline mode” in web browsers? Because that’s what back/forward should still be… instant “offline mode”!
Anyway, on to the second (and final) part of this browser brokenness brouhaha.
SSL Secure Certificates!
Way back in the day, a secure certificate for your website meant two things:
And way back in the day, in order for a trusted authority (trusted by the web browser developers) to sell you any secure certificate, they first actually did a little background checking (you had to fax them – in South Africa – some sort of proof of your organizational status b.s.).
Nowadays, buying a secure certificate is an entirely automated process: one that only requires you to have access to an email address @ the domain you’re buying the certificate for. All a secure certificate is telling you nowadays is that:
Rewind
I’d like to now take a moment to step back and think about what benefits secure certificates provide to the end user.
They encrypt your data. Okay, although I’m not sure there’s ever been a reported case of a third party sniffing sensitive information on the Internet as it passed through their routers, I can at least see the theoretical benefit this provides.
They verify that the owner of the domain you see in your web browser has paid some money to some company that has paid some money to the creator of your web browser. I don’t see any benefit to this. In fact, I see several drawbacks to this.
For one, users don’t necessarily realize that the only thing that little lock icon is telling them is, that yes, just like their location bar says, they really are connecting to banchofamerica.com!
Phishing has hopefully taught us that the average end-user doesn’t really understand the way URLs are formed, and the fact that they REALLY ARE connecting to brankofamerica.com or www.bo/fa.com/signin.cfm means exactly bum diddly nacho to whether or not the information they are about to type into this web site is securely going where they think it is.
In fact, having that little “secure lock” icon, or any of those other “mcafee site advisor”/”verisign secured seal” logos as a proxy for actually critically examining the site you’re sending info to is a lazy cop-out that doesn’t work.
Secondly, by putting up this artificial barrier to encrypting website traffic, you’re discouraging people from using encryption. I mean, anybody can easily make a self-signed secure certificate for free (from our panel) and get 100% of the encryption benefits of these expensive certs.. but they don’t because browsers bring up a TERRIFYING WARNING that … oh horror of horrors … this certificate was not created by a trusted authority!
Of course, there are other reasons that people don’t use encryption (slightly slower, caching issues!) on websites, but as things are now, if you do want to do it, you’d better be ready to put up with a little extortion!
What should web browsers do?
They should give up on “trusted” certificate authorities. Only tell us that a site is encrypted or not, and then do some anti-phishing checks to see if hey, the site you’re visiting looks like it’s Bank of America, but it’s URL is Bunk of America! (.vn!)
(There are already plenty of anti-phishing technologies being built-in to browsers these days. I’m not sure if they do this or not, but what if a person has saved any login info with the browser, you warn them (heavily) when they try and submit that same login info to a different site! Because everybody uses the same throw-away login info for a ton of unimportant sites, only do this check on a list of heavily phished sites, e.g. ebay/paypal/banks/gmail/etc..)
Other than the phishing issue, what exactly is the point of verifying that the web site you’re visiting is “who they say they are”?
They may be a totally “legit” business who just doesn’t do the best job of storing their customer’s private data. They may be a “legit” company that has poor customer service policies. They may be a “legit” company who practices the best security and customer service, but their web site just looks like it was thrown together by some Vietnamese teenagers.
What can we do about it?
Well, I was thinking about offering a bounty of $1000 for a plugin for Firefox/Chrome that would make it consider any certificate signer a “trusted” certificate signer, but I figured that’d probably rile up all kinds of people and security nerds.
So, rather than trying to bring down “trusted” secure certs… we’re going to bring “trusted” secure certs down… to all kinds of people!
By offering them for just $15/year… forever!
Which, I’m pretty sure, is the cheapest price offered anywhere… by far. This offer is (currently) only good for existing DreamHost customers.. you can add your certificate from our panel’s Manage Domain area.
These certificates are exactly the same as what we used to sell for $100/year! They’re not going to cause any pop-ups in any of your site visitor browsers, and they really do encrypt the data. You can use them with us or any other web host. The reason they’re so cheap is we’re now reselling a different “trusted” certificate signer and our volume is enough that we’ve got a much much better price… and we’re not making anything on them because we feel the whole business is a scam!
51 Responses to “Broken Browsers Part Two”
Categories:
Archives:
- November 2009 (3)
- October 2009 (1)
- September 2009 (3)
- July 2009 (1)
- June 2009 (3)
- May 2009 (3)
- April 2009 (4)
- March 2009 (2)
- February 2009 (3)
- January 2009 (3)
- December 2008 (3)
- November 2008 (4)
- October 2008 (5)
- September 2008 (2)
- August 2008 (5)
- July 2008 (2)
- June 2008 (3)
- May 2008 (6)
- April 2008 (2)
- March 2008 (3)
- February 2008 (5)
- January 2008 (7)
- December 2007 (3)
- November 2007 (3)
- October 2007 (5)
- September 2007 (3)
- August 2007 (4)
- July 2007 (4)
- June 2007 (7)
- May 2007 (3)
- April 2007 (3)
- March 2007 (8)
- February 2007 (4)
- January 2007 (6)
- December 2006 (5)
- November 2006 (2)
- October 2006 (4)
- September 2006 (4)
- August 2006 (5)
- July 2006 (3)
- June 2006 (3)
- May 2006 (5)
- April 2006 (6)
- March 2006 (7)
- February 2006 (6)
- January 2006 (8)
- December 2005 (7)
- November 2005 (5)
- October 2005 (8)
- September 2005 (19)
- August 2005 (11)
- July 2005 (4)
Other Sites
- DreamHost Status - An off-network page for all DreamHost Announcements! (Not as silly as this blog.)
- DreamHost! - The host behind the blog.
- Forum - Discuss DreamHost and web hosting!
- Web Control Panel - Manage your account.
- Wiki - On DreamHost and web hosting.
Powered by WordPress. Pool theme by Borja Fernandez, modified by DreamHost.
Like WordPress? Consider attending WordCamp LA.
Entries and comments feeds.
^Top^
May 28th, 2009 at 4:24 pm
Swell, it’s $15 per year, but you still need a Unique IP address for $3.95/month. Still not worth it to me.
May 28th, 2009 at 4:29 pm
Ah yeah, that’s true! I almost forgot about that.
There is hope on the horizon in terms of IPv6 and “SLI” (SSL on a shared IP), but both of those are probably at least a year or two away still.
josh!
May 28th, 2009 at 4:46 pm
This is awesome enough to warrant a comment:
awesome.
May 28th, 2009 at 4:54 pm
Why is SSL on a shared IP still at least a year away? Don’t most browsers support TLS SNI nowadays?
May 28th, 2009 at 5:05 pm
Not quite. It tells you that if the domain name is correct, then you aren’t being man-in-the-middled; the CA has verified ownership of the domain name in some out-of-band manner. If browsers only told you that the connection is encrypted, it would not be safe to load https://panel.dreamhost.com/ from a coffee shop.
The reason most certificates aren’t free is that even domain validation is hard to do right.
May 28th, 2009 at 5:06 pm
This is sweet! $15 for a no-hassle ssl cert is great.
May 28th, 2009 at 5:13 pm
I’m confused about your complaint about POST dialogs in Firefox when clicking the back button. Firefox is quite liberal about caching for session history.
By default, you’ll only see that dialog on sites that send the no-store header, which specifically asks the browser to not cache for session history. And the only reason Firefox supports no-store is due to blackmail from banking web sites, which want “log out” links to be completely effective on shared computers.
If you ever see such a dialog when clicking back to a site that does not use no-store, you should file a bug report with precise steps to reproduce.
Is it possible that you have strange settings, such as having turned off Firefox’s memory cache?
May 28th, 2009 at 5:18 pm
A Firefox extension along these lines already exists. It is called MITM Me. But I don’t understand why you’d want to make encrypted but unauthenticated connections.
(Johnath and I both work for Mozilla, and we both host our blogs on DreamHost.)
May 28th, 2009 at 5:31 pm
For the coffee house example.. I guess you’re saying they put in some fake dns for panel.dreamhost.com to go to their server, self-sign a cert and boom, you’re none the wiser?
But, instead, that cert is signed by somebody like verisign, so your web browser knows to trust them.
But… couldn’t the evil coffee shop just make a fake cert that SAYS it’s signed by verisign, and then hijack verisign’s dns or whatever as well so when your laptop web browser checks with verisign that it IS real, fake verisign says “sure is!”?
josh!
P.S. About firefox, I guess what I’m saying is yeah, they shouldn’t be black-mailed by banking websites to listen to some silly “no-store” header the server sends! Or at least there should be a plugin or option to ignore it if you’re personally willing to take that risk.
May 28th, 2009 at 5:44 pm
The whole blackmail thing is pretty weird, and seems to prevent Firefox from even including an option to ignore no-store.
If you see any sites using no-store that shouldn’t be using it, please yell at them ;) I also wish banks would try to avoid triggering the dialog by using AJAX, avoiding POST for everything other than actual transactions, or redirecting after each POST request.
Does the BetterCache extension do what you want?
May 28th, 2009 at 5:47 pm
Your “fake verisign DNS” trick doesn’t work because Firefox ships with Verisign’s public key (or something like that). Firefox won’t accept a fake Verisign cert.
May 28th, 2009 at 6:07 pm
If you’re interested in becoming a non-reseller CA, check out Mozilla’s CA policy. Mozilla doesn’t charge for inclusion; it just wants to be sure your setup is secure. I’m not sure how much that will end up costing you, or how many other browsers you’ll be able to get into just by meeting those criteria, but maybe you can offer “Free SSL in Firefox” as part of domain registration or web hosting.
May 28th, 2009 at 6:34 pm
It’s great that DreamHost customers can now get certs cheaply and easily. I used to get my certs from GoDaddy, which is cheap but involves over an hour of account jockeying, copying/pasting, unzipping, and guessing.
Don’t forget to update your What’s Included page with the new price!
May 28th, 2009 at 9:06 pm
@Josh
Are these wildcard SSL?
Where I can have multiple sub-domains all on the same SSL certificate … but if that’s the case, this would be extra-super-duper awesomeness!!!
May 28th, 2009 at 9:07 pm
@Josh
Are these wildcard SSL certificate?
Where I can have multiple sub-domains all on the same SSL certificate … because if that’s the case, this would be extra-super-duper awesomeness!!!
May 29th, 2009 at 3:45 am
Ouch. Please download ‘Cain and Abel’ and enable ARP spoofing. Then ask some of your friends (who are connected to the same router as you) to do their banking, email etc and IGNORE the stupid browsers warning about non-signed certificates. The software will then conveniently provide you with text files containing the whole encrypted conversation – in plain text, that is. This man-in-the-middle attack can be done by any 12-year-old on their windows home network. Setup time: 10 minutes.
May 29th, 2009 at 5:22 am
I won’t add much to the comments Jesse’s already made, but the short answer is: no, a rogue AP cannot pretend to be Verisign unless they have uncovered some Very Interesting Mathematical Results.
The deal is that there are all kinds of point and click packages now that will:
a) Set up a rogue AP using your laptop’s wireless adapter
b) Log all the plaintext traffic
c) DNS spoof to your heart’s content
d) On https connections, generate a self-signed cert to try to masquerade as the legitimate site.
The only thing that lets us spot the attack, in the last case, is that the cert is not signed by a trusted authority who verifies domain ownership. Unless you’ve broken RSA key exchange, or stolen a trusted CA’s private key, you cannot produce a cert that will convince us it came from the real thing.
If you’re using a self-signed cert to encrypt traffic to your webmail server that you and three friends share, and you don’t want to spend the $15, so be it – get them to add an exception, Firefox will start trusting that cert to identify that mail server, and will even spot it if some *other* cert tries to intercept. But for anything public, where you expect any significant number of users, and where anything of any value whatsoever is being exchanged, get a verified cert. I don’t think that’s too much to ask, to mitigate a real attack, and it’s been nice to see other browsers following suit.
I wrote more about this here, if you’re still interested:
http://blog.johnath.com/2008/08/05/ssl-question-corner/
May 29th, 2009 at 5:34 am
I agree and disagree. I agree that the whole security cert companies are somewhat scamming, or possibly price-fixing since the price has been about 100/year (or more) for quite a while if you wanted one from one of the “big boys”.
I don’t agree that background checks should be performed on every application: quite simply they can’t. They could do that back in the day when they got like 50 applications per year. Today those applications would be in the 1000s, 10s of thousands, or more. If they performed a background check on every application there would be a waiting time of 5+ years for an application to be reviewed! The background checks now fall into the hands of average Joe user browsing the web. Yes, it is unfortunate that those unlucky enough and unknowing of phishing scam practices get baited, but when they do they can complain to the authority about X certificate. The authority can then look into the matter, perform a background check on said offending certificate owner, and if something seems odd about them they can revoke the certificate.
May 29th, 2009 at 7:12 am
I’m with sdayman, unique ip is still needed. Wish long time customers got some of the perks of the new customers, think there is a new customer code to get 3 unique IPs for free for life, that would come in handy right now.
May 29th, 2009 at 7:14 am
Awesome!!!!! This totally rocks!! I’ve been meaning to get cert lately. This is a happy day for me! Thanks DH!
May 29th, 2009 at 8:28 am
What’s the best way to get a cert I can use on another host?
May 29th, 2009 at 8:45 am
Josh, (disclaimer: I host my site at Dreamhost)
You don’t understand how CA’s and certs work. In your coffee house example, you said they could MITM the DNS for panel.dreamhost.com and then MITM the DNS for VeriSign too.
That’s not true. The “real” cert is signed by a CA’s certificate using their private key, verified by a known public key. This public key is stored in the browser in Firefox, and in the certificate store in Internet Explorer. It’s not using Internet communication to verify this at all.
Internet communication is only used to check the certificate revocation list, and that is done via SSL, which then takes into account certs signed by a CA cert (or by a cert that a CA signed with a flag that says it can sign other certs, most likely, like your reseller provider).
So yes, SSL certs are still VERY useful and DO prevent MITM attacks. Please update your post with this information. Jesse is absolutely right.
What I’d really like to see you do in addition is offer code signing certificates (Authenticode). As a software developer, the prices for these are outrageous (at LEAST $199/year [GoDaddy]).
May 29th, 2009 at 9:59 am
Of course, this depends on banking websites and all those other sites that switch people to https connections to be made in such a manner that they cannot be corrupted, and that users know all the possible domains that their bank may switch you to in the course of you clicking that “Log in Securely” button on their home page.
http://www.forbes.com/2009/02/18/black-hat-hackers-technology-security_0218_blackhat.html
May 29th, 2009 at 10:17 am
Hear, hear. Excellent points all, and your peerless tirade against SSL deserves to be linked from here to kingdom come.
But, you say this: “Nowadays, buying a secure certificate is an entirely automated process…”
This is true in every instance except Extended Validation SSL. People go back and forth on whether the green url means anything, but I’ve had a few clients go through the process of obtaining ev certs and the background check is fairly robust, digging into both ethics (generally speaking) and identity. Now, one could complain about why EV is considered a “extra” technology rather than being standard (ie, why are we even issuing regular certs anymore given the info above?), but at least there is an option out there that takes a handful of these shortcomings into consideration.
May 29th, 2009 at 11:06 am
I’ve got a MITM attack for your 5 bit encryption right here:
http://www.worldofstock.com/slides/MES1670.jpg
pwned!
May 29th, 2009 at 12:29 pm
Okay yeah, you guys got me! I guess I mostly just needed something to rant about to go with the SSL price drop! :)
And, the certs are only for one domain (though they do work for both domain.com and http://www.domain.com), our reseller still charges like $150/year or something for catch-all certificates. I don’t know why.
But yeah, why ANY trusted cert is more than maybe $10/year is pretty much insane to me! Too big a barrier to entry I suppose.
Maybe the bigger bug here is at least in chrome, I can’t seem to get it to recognize the self-signed certs we use around dreamhost for internal things so I can stop getting those dang-gone pop-ups every time I re-open my browser!
josh!
May 29th, 2009 at 12:38 pm
Aurghh. This is really dissapointing.
The reason CA’s charge significant amounts of money is that to do the job right requires time and effort. You have to be checking government id’s, or doing other verification steps to prove you are who you say you are.
Dreamhost selling these to any member is a horribly bad idea. I can just claim to be royal-bank-card.ca and get a cert from you saying that. That means when people come to my website, I say “Hey look, I’m really this person. You can trust me, Dreamhost trusts me!” If Dreamhost is arbitrarily trusting anyone and everyone, it’s the sort of thing that should get their right to sign other certificates revoked by the person who signed YOUR certificate…
May 29th, 2009 at 1:34 pm
Are these SSL certificates Root-Level?
May 29th, 2009 at 1:40 pm
I don’t care for what other people say here. I just want to thank you guys for all this awesomeness!
I am proud for being a happy DreamHoster.
May 29th, 2009 at 2:42 pm
I think some people are missing the point that the human element is what gets everything messed up here.
When my Dad goes to a website and sees the ssl lock he might think OK this is trusted… but in reality the connection is ‘trusted’ not the provider. And the 100 dollar cost of this veneer is being held in place as a substitute for any authentic real world ‘trust’.
I might not be able to supplant a verisign connection using bank, but for all practical purposes I can reproduce the experience and offer them my own ssl ’security’ to boot.
Another thing to consider is that this blog post probably self selects a demo of people who really aren’t capable of understanding the true noob perspective.
Personally, I think those security logos on the bottom of all your bases are an ugly joke on you. You know who uses those the most? Credit cards and banks, the same companies that rip us off day in and day out. There is a larger rant her, but I will shovel it before things get completely crazy and someone brings up the nazis… oh shiiiii…
May 29th, 2009 at 2:44 pm
PS. Best use of the blink tag this month.
May 29th, 2009 at 4:28 pm
Is there any way you could offer wildcard (*.domain.com) certificates? I find these are the best, since you don’t have to puchase separate certs for each subdomain (yet another scam.. hehe).
Also, will it ever be possible to purchase certs through you without signing up for the unique IP (i.e. for use elsewhere.. not that anyone would ever host anything anywhere else!! ;-)?
May 29th, 2009 at 4:35 pm
Ironically, and sadly, I hadn’t seen this blog post before I went to theplanet.com, where also sell certs for $15/yr, I’d have preferred to give DH the cash (electronic or otherwise). Doh.
May 29th, 2009 at 5:00 pm
Good news!
1) I suppose that now dreamhost need also to update price in this page too: http://dreamhost.com/hosting-features.html#ssl
2) In simple words, if I have some domains on dreamhost, but hosted on a VPS with 2 IP, I need also to rent the IP to dreamhost, or is enough my actual used IP?
May 29th, 2009 at 9:52 pm
Josh,
Glad to see the v6 mention in your comment and on the newsletter. I’m also happy to see DH got a /32 of v6 and is advertising it via Comcast.
I actually know of a couple of networks that will be v6 only this year (still NAT-PT ghetto v4 connectivity). It’s really about time a shared hosting provider got on the v6 bandwagon. Thanks!
Btw, any chance of getting a v6 rollout to servers/private servers prior to panel/vhost configs. While you’re @ it, v6 NS glue? :D
May 30th, 2009 at 7:15 am
Has anyone successfully installed a new $15 SSL certificate?
Before buying, I’d like to see your https website to check whether it’s compatible with 99% of the browsers as advertised…
May 30th, 2009 at 8:02 pm
Incidentally, there’s some thoughtful discussion of the merits of various kinds of CAs on a Mozilla bug requesting inclusion of the CAcert root certificate: https://bugzilla.mozilla.org/show_bug.cgi?id=215243 .
May 31st, 2009 at 7:40 am
Jeremy Nickurak: I don’t see how the background check justifies the cost. You’re assuming that the background check is trustworthy. If cert vendor X says someone has passed a background check, why should I trust that? I don’t know what their background check is, so why would I want to pay for someone else’s background check? The background check doesn’t benefit me, my users won’t know exactly what is being checked so they have no reason to trust it, nobody but the certificate signer knows what’s in the check or what came of the check and yet I’m being asked to pay when I get a signed certificate from them.
If a cert business wants to do background checks and only distribute certs to those who pass the check, fine. That’s their policy and it probably does cost them something to implement that policy, so they should pay for it. It does not follow that I should pay for that. This entire arrangement still strikes me as almost entirely a scam.
May 31st, 2009 at 6:50 pm
@Jeremy Nickurak SSL certificate providers have not done any sort of background checks (or really, much of anything) for most SSL certificates for years now. Most of them just charge as if they do, and charge even more absurd prices when they actually DO do some work (such as for for EV SSL certificates).
May 31st, 2009 at 10:33 pm
@JB What I’ve seen is that when CAs do background checks they also post bonds stating that the person is who they verified that the person is. So the quality of the background check would be however large the bond that they posted is I guess, plus the difficulty of proving that they did not properly verify the person I guess.
June 2nd, 2009 at 11:44 am
actually, on the coffee shop example, they could simply add an exception to firefox, or create a self-signed CA pretending to be verisign, add the root certificate to IE and Firefox (after all they have control over the whole computer), and sign all their fake certs with their fake CA. nor firefox nor IE would raise any warning, and the average user would never know, because I’m guessing only very paranoid (and skillful in this matter) people check ALL the info of ALL the certificates EVERY time they are connecting to a secure site.
@JB the whole point of CAs is the trust thing. its a very complicated process to be a “trusted” (one that would not issue any warning on any browser) CA, so this kind of guarantee to the user they can trust the CA methods, as they already have to be part of a network of “trusted” CAs. not that this can’t be easily circunvented if you have control over the user machine anyway…
Those new green certs came to address the problem of the CAs methods, thats why the are much more expensive. I personally think thats the wrong approach.
the sulution could be: there are some free CA that already work on firefox, we just need then to work on IE and the problem is solved, so if you just need the encryption you go for a free one, and if you want to make the user sure you are a legitimate company, you go for a “green” certificate, that REALLY verify your company info. This way the high cost of these green certificates could be as high as they want, as only big companies that have the money need this kind of thing.
on a side note, if you are not at least familiar with this matter, its NOT secure to input sensitive information on YOUR computer, and if you are using a third party computer its not secure AT ALL, NO MATTER WHAT YOU DO.
June 2nd, 2009 at 8:59 pm
Hear, hear!
A customer of mine has had an SSL cert for their domain for several years in spite of the fact that the ONLY evidence he provided the cert vendor that he owned the domain was the fact that his email address is located at the domain he bought the cert for. Oh, and that he had twenty dollars more before he bought the cert than afterwards. Now, while it actually is his domain, I can’t see any way for the cert vendor to have known it – his credit card’s under a different name than the whois info for the domain, the whois info itself points at a mailbox he hasn’t had for years, the mailing address on the domain is similarly outdated and doesn’t match his credit card… I actually had more sanity-checking done on my identity when I bought a domain out of a Monaconese registrar that can’t even manage to stop their order forms from switching into French at random!
However, blindly accepting all certs is not the best solution – it will make monkey-in-the-middle attacks almost as easy (if a bit more CPU-intensive) as intercepting plaintext, and unencrypted traffic is widely intercepted by potentially-hostile parties (If you want an example, there is a spamvertised domain at http://www.tradeim.com/ , hosted in China. Their site currently loads a nice ugly webpage. Once you’ve verified that it works, go to http://www.tradeim.com/?Falun+Gong . Your connection will be broken, and you will be unable to load webpages from http://www.tradeim.com until China’s firewall forgets about your fascination with the Falun Gong. Keep it up and they’ll even block SSH connections to http://www.tradeim.com.)
IMO, the Right Way to handle SSL certificates is not to blindly Trust, but rather to treat them ALL as untrustworthy and show you the certificate chain and fingerprint info for each new cert you encounter, much like SSH or the Yeemp instant messenger do. (Which reminds me, I really should reactivate my Yeemp server sometime.) – then cache the accepted certs forever and warn you in great firy letters of DOOM if the cert changes. If I inspected the cert chain for bankofthewest.com and accepted it, the mere fact that pankofthewest.com has a new cert should make me blink and double-check before logging in.
June 3rd, 2009 at 5:42 pm
Hi, many of the commenters already stated above, and they’re right.
SSL certificates are still a great way of knowing whether your communication is being intercepted or not.
If anyone can ARP spoof you (what is 99.999999% of the time possible) they can forge their own certificate and decrypt your communication, even though your browser shows a padlock.
June 5th, 2009 at 9:10 pm
This post is remarkably retarded. Without trusted signing, encryption doesn’t -mean- anything. An attacker can encrypt a web-site, too.
As for “I’m not sure there’s ever been a reported case of a third party sniffing sensitive information on the Internet as it passed through their routers”, are you completely daft?
As a teenager I regularly used arp spoofing to MITM, sniff, and forward network traffic on the local LAN. Nowdays I could do the same in a coffee shop or at a conference, if I was so inclined.
Seeing as this remarkably ignorant drivel is coming from the CEO of DreamHost, I think it’s pretty clear that I shouldn’t trust your services to be even remotely secure.
June 10th, 2009 at 11:51 pm
There is a plugin called “Perspectives” that both suppresses the annoying warnings when using self-signed certificates and, as a bonus, prevents you from MITM-attacks. http://securityandthe.net/2008/10/20/bypassing-https-warnings-in-firefox/
June 18th, 2009 at 7:54 pm
Too bad it still requires a $3.95/year IP, even for certs “you can use elsewhere” – I guess I’ll pop over to The Planet to save that!
June 29th, 2009 at 6:11 pm
It’s not $100 a year, for sure. It’s “just” $47 which is the price of the unique IP. This ruined any possible technical explanation of the “benefits” of buying DH’s SSL that came later. If even the price isn’t right, the technical details provided by DH are much probably wrong as well.
July 4th, 2009 at 8:42 am
its a very complicated process to be a “trusted” (one that would not issue any warning on any browser) CA, so this kind of guarantee to the user they can trust the CA methods, as they already have to be part of a network of “trusted” CAs.
July 8th, 2009 at 1:32 am
If cert vendor X says someone has passed a background check, why should I trust that? I don’t know what their background check is, so why would I want to pay for someone else’s background check? The background check doesn’t benefit me, my users won’t know exactly what is being checked so they have no reason to trust it
July 8th, 2009 at 1:37 am
The software will then conveniently provide you with text files containing the whole encrypted conversation – in plain text, that is. This man-in-the-middle attack can be done by any 12-year-old on their windows home network.
July 17th, 2009 at 3:35 pm
Wow this is gonna be so cool.