Do you have to pay to watch the Olympics in China?
I don't know. Didn't we have to pay to watch them here?
Not as in "pay-per-view", but as in "over broadcast TV"?
Even if we're talking about actually-free channels (do any still exist?), there's still the matter of ad revenue. If people just put clips up on YouTube, that means Google gets the revenue, instead of the Chinese Government.
Customs, at least, has been known to demand the keys to a laptop, and having it obviously encrypted could delay travel significantly.
Also, there are significant problems with at least some FDE products, currently -- the "cold boot" cracks, in particular. Does she shut her laptop down every time, or only leave it on standby? Does the software actually purge the key from RAM on shutdown?
I'd suggest BitLocker, mostly because it's built-in -- kind of like, "What would you suggest for unzipping files in Windows XP?" Well, probably the "Compressed Folder" feature, right?
Under other circumstances, I'd recommend Truecrypt or dm_crypt, because you really should be using open source software for anything sensitive -- but you specifically asked for Vista, so that's fairly moot.
I wish you would EXPLAIN WHY instead of just saying it is.
It falls under "hiding things from the user", which I generally consider to be bad -- and could have unpredictable results.
A contrived example: I've installed a new BB system -- or blogging engine -- whatever. I've configured everything properly, or so I think, and I'm wondering why most pages work, but certain pages just seem to hang forever.
Or, alternatively, I'm trying to access someone else's site, through a heavily restrictive censoring firewall. Again, certain pages work as intended, and certain pages hang forever, until the connection times out.
With at least some distinction in the URL scheme, I might think to myself, "Aha! These are SSL requests of some kind! Port 443 must be blocked somewhere!"
Requiring people stealing your mail to go to all that trouble, instead of letting everyone read and write on your mail and happily send it on its way with no trouble at all.
Given that all of this must be done manually -- calling the post office, intercepting the mail, physically opening the envelope, finding an identical one, and replacing it -- or opening it carefully, so as to be able to re-seal it with no evidence of tampering -- all of this requires a significant investment of time and effort, and a small investment of money.
All you're doing is requiring people to download a somewhat more sophisticated version of airpwn. Kind of like how using rot13 is pretty pointless, for any data you actually care about. Security through obscurity, plain and simple.
I haven't actually seen that for awhile now. My DSL modem operated in bridge mode. Currently, my router -- a Linux router, which can, indeed, spoof a Mac address -- is on fiber, and has a real, live IP address. Every Linksys router I've seen lately has something called "mac clone", which is explicitly designed to spoof a Mac address -- I assume that's actually useful somewhere. (I've used it when my ISP doesn't want to let go of my DHCP lease.)
Oh, and this is at a university. When I was there, it was all a local Ethernet network -- which, in fact, was handing out live IP addresses, but it'd be worse if they didn't. The only saving grace for the RIAA was, my school required users to register their Mac addresses with an account, and that account was actually tied to their identity.
you should research browser recognition rates and 2nd year renewal charges for ssl certs before going wiseass on them.
The one I mentioned lists all sorts of browsers, everything from the major ones to "Red Hat Linux Konqueror" -- and while I can't find any extra fees for renewals, I do see discounts for renewals.
You are arguing in circles. The reason it cost that much is that Godaddy gives you your own IP and cert.
Fine. You write the scenario.
I'm on Slicehost -- that's $20/mo. IP is included. Cert is, as I've said repeatedly, $15/year. (Except when I thought it was $10/year -- sorry about that.) Insignificant next to hosting costs.
I suspect that if there was demand for it, which means it wouldn't pop warnings up all over the place, they'd give everyone SSL access, using a wildcard cert, via HTTPS, to their existing websites. For no cost.
Well, there are two options there:
Either you put everyone on a subdomain, or a subpath of the same domain -- think Freewebs -- and this might cause XSS issues...
Or you actually start handing out certs for free, without doing any background checks. That wouldn't cause giant warnings -- until the people Godaddy is reselling from invalidated their cert, and/or browsers started removing that root cert, as it's obviously not trustworthy for verifying identity.
(And you're assuming they wouldn't want to use that demand to basically print money.)
Or, you do the background checks -- but this costs money. How do you earn it back? One way is to charge people for the service of identifying them, and... hey! That's how SSL works right now.
Passports -- real, physical ones, that you use to go to other countries -- aren't free, either.
Moreover, I'm failing to see why you think that failing to see why a MitM attack would be implemented somehow demonstrates your point.
Actually, I was talking about your passive attacks.
Or, heck, just present an invalid cert, and insert a message on the cleartext webpage to click past it, and quite a lot of people would click past it.
Which is actually an argument for my point -- make the warning bigger and more obnoxious, so that people actually realize that there's a real security implication, not just another thing to click through without reading.
You have no objection except the time it would take?
Given that you're talking about implementing a whole new URI scheme, and pushing it into major browsers, I think that's a lot of time. I'm not even counting time to educate users.
Given that one of your complaints about my suggestion to "just get a real cert" is that SSL with virtualhosts isn't widely supported enough, I also don't really see the point. We've now, again, reduced the cost of real SSL to $15/year, or $1.25/month -- and that would have wider support than "httpe".
However, making it indistinguishable from plaintext is a bad idea. Making it indistinguishable from verified SSL -- or allowing the possibility for someone to confuse it with SSL -- is a much worse idea. That is what I was arguing against.
And I still don't like it. I think the benefit from it is so small (really, certs are cheap), and the implications are yet another thing which people should learn in order to be secure on the Internet, that it would be better not to have it.
And I think that, moreover, there would be a brand new meme of misinformation that your httpe is "secure enough" for whatever purpose, among people who otherwise would buy a cert, and would be better off for it. (Take rubyforge.org as a shining example of someone who already does this with self-signed certs -- though maybe I should ask and find out why they do it that way.)
But at this point, I think I'm done. After all, my browser already supports things like a fish:// URL scheme, as well as zip:/ and other fun things. People invent new URL schemes all the time -- there's steam:// for Valve products on Windows, "magnet links" for Azureus and friends...
So ultimately, my objections don't matter. Either you'll get it standardized, in which case, it'll hopefully be much more thoroughly debated (and be much improved as a result) -- or you won't, in which case, it'll be a nonstandard extension, something between you and your users, and my opinion won't really matter (kind of like Flash -- fucking Flash...)
And I notice you completely ignored the 'And we don't have infinite IPs either' point when I demonstrated that the majority of web browsers do not support them.
You've got one, right?
How many domains do you need to support, exactly?
Online businesses obviously need authentication. A guy who can barely afford godaddy to run his joomla discussion board does not.
First, Joomla? Really?
Second, why does this disqualify him from needing authentication? All you're talking about is the economic impact (which I've demonstrated as pretty small). If we're assuming he actually can run SSL, which implies that he has his own virtual host, Godaddy charges something like $40/mo for that -- an additional cert (for a plan which doesn't actually include a free one) is going to be less than $2/mo.
That doesn't mean that I can't say 'I wish the web browser would encode this password using the encryption built in, instead of something written in this annoying language'.
Javascript is actally fairly powerful, and often misunderstood, but that's beside the point. It has a builtin method for exactly what you're asking, which is called HTTP auth. You just find it ugly.
It's a frickin giant dialog box, entirely breaking the paradigm of the web.
Paradigm? I don't think that word means what you think it means...
And it really doesn't, much -- you would just be implementing exactly the same thing in an HTML form, maybe with some javascript. It has the added advantage of being uniform -- every page that uses HTTP Auth will provide the same login form.
How the heck is that 'heavy handed'? I have no problem with it.
That's a great definition of "not heavy-handed" -- "something I have no problem with." That's serious Godwinbait.
I'd be happy with a newly-defined 'httpe' or something, for encrypted but non-authenticated connections.
Fine, go ahead. I don't think it's worth the effort it'd take to implement, but that's me.
Sure, it sounds crazy, but if people see a few giant security warnings, they could quite legitimately assume everywhere there's not a warning is secure.
That actually is pretty crazy. When driving past a prison, you see giant signs that say "Do not pick up hitchhikers." Does anyone assume that hitchhikers are 100% safe everywhere else?
There are at least two orders of magnitude difference needed to log web pages, especially if you're just grabbing the headers and POST variables, and needed to read, decrypt, reencypt, and send along web pages. Especially if you have to check which are signed by a known CA and not alter them.
Are you talking about performance?
In other words, it takes a few orders of magnitude more clock cycles on my laptop when I airpwn you. What does it matter to me, as long as I have enough?
Or are you assuming that I'd be trying to crack quite a lot more connections at once? What's the motive? Where is it that I have the opportunity to intercept enough traffic that the "orders of magnitude harder" even matters -- and for what purpose do I need that much data?
I'm not trying to say "you have nothing to hide" -- what I am saying is that I don't see a scenario where such an attack would make sense -- where it would have an economic incentive, even.
Especially if you have to check which are signed by a known CA and not alter them.
Which you don't, really.
Remember, you'd have to intercept all communications. You couldn't encrypt half with one key and let the rest pass buy.
First, I only need to accept all communications from the client I'm trying to 0wn. I don't need to intercept all communications from everyone.
Aaaaaand....cue the personal attacks and insinuations.
This isn't personal. Minimum wage in this country is more than enough to afford $15/year for a cheap certificate. As an expense for a business, it should be minimal.
For the amount of time and effort you've put into arguing with me, at a decent wage, you could probably afford two certificates, or the same certificate for two years.
You haven't actually provided a counterargument -- you've just refused to answer it as a personal attack.
It's fine if there's no indication at all it's an encrypted connection.
Seems outside the scope of SSL. Or rather, under that scope. And as you stated above, you already have two options: HTTP auth and Javascript.
All your yammering about people being 'fooled' requires people somehow being smart enough to figure out they're on encrypted connection, and yet dumb enough to not realize it's not signed by a trusted authority.
For over a decade, there has been a lock icon in the taskbar, and https in the URL -- and we've been training users to look for these signs. A green address bar is nice, yes, but what you're proposing is that we completely retrain users to look for completely different clues for "this is an encrypted connection that I trust" and "this is just some random encrypted connection".
That, or you're proposing that we hide the crypto from users entirely -- which seems just as heavy-handed as throwing up gigantic warnings. So much for wanting choice.
(Which, despite what people seem to think, actually is a hell of a lot easier than MitMing a connection.)
Seems you didn't actually have a counter for my airpwn link.
Give me one situation where someone would "trivially snoop on a connection" without also being able to trivially run an SSL MITM attack, and trivially snoop on your wish-it-was-SSL connection.
For one, *I don't CARE* about MITM attacks - they are 10000 times harder to pull off than basic wireless or ethernet snooping at a hotel, Internet cafe, or on a LAN.
Maybe so, but I don't have to, because someone else already has. Downloading Wireshark and downloading Airpwn are equally trivial. Implementing Wireshark is probably harder than implementing Airpwn, but that's really irrelevant.
And if your attitude becomes common, how soon before the same kinds of automated passive attacks are replaced with automated active attacks?
If I wanted to be treated like I'm stupid and prevented from doing things that I want to do because a browser thinks it would be better that way, then I'd use IE.
Major difference: IE won't give you a choice. If you feel so strongly about this behavior in Firefox, go patch it. Or, if you're not a developer (or feeling particularly lazy), file a bug asking for the ability to turn this off, or troll around looking for people willing to fork the browser.
For what it's worth, even SSH behaves like this. If you SSH to a host which is unknown, you'll get a big ugly warning -- and it will then keep track of that host key. If you SSH to a host whose key has changed, you will get a GIANT ERROR, which in BIG SCARY CAPS tells you that it's possible someone's intercepting your traffic RIGHT NOW OMG!
And there is no way to override it short of removing the key manually from the config file -- which is a good deal harder than four clicks.
I would think SSH is the kind of tool power users would be using for themselves. It's the kind of place you would expect people to be well-educated about this sort of thing, and where you'd expect people to not want their decisions made for them.
But they chose to make it difficult to be insecure.
Do you check the signatures on your browser every time you install it or update it to make sure the upstream source wasn't tampered with?
Actually, yes. Specifically, apt uses GPG to check them. Every install, every update -- of every app on the system. I therefore open myself up to a MITM exactly once -- when I download the install CD.
Do you check your keyboard plug every time you sit down at your desktop to make sure there isn't a logger on it?
Actually, I carry my keyboard with me. Not for security reasons, but it does kind of make this moot.
Do you cover your keyboard everytime you enter your password to make sure nobody is watching?
No. I do, however, use Dvorak, and type extremely fast. Someone would have to be watching very carefully, or recording it to play back at a slower speed. And that password is only used locally -- the passwords I use remotely, I mostly have my browser memorize, or they're keys instead of passwords -- so they would have to steal my machine in order to do it.
In the case of my laptop, they would also have to steal my USB key, or they'd have to very, very quickly perform a cold-boot exploit.
There are thousands of potential vulnerabilities that exist every time you use your computer
I don't see that as a reason to introduce more.
quit making it out like it's worthless without authentication - it's not.
Actually, it kind of is. Without authentication, it is security through obscurity -- you're basically praying that no one who is capable of sniffing your packets realizes that they could probably alter them, too.
Now, by some arguments, it's not completely useless. After all, neither is the "two-factor authentication" employed by most banks -- since it is theoretically possible that someone would collect your password, but not the answer to your security question.
But the payoff is so low, at this point, that I don't see why you'd bother -- and I think it's dangerous to support it at all, because it provides a false sense of security.
If that's your argument, it's pretty pathetic. A quick Google for "Cheap SSL", and within the top ten results is another provider who's under $30/year. Found another at $25/year. A few others are at $60/year -- that's $5/mo.
Godaddy is still the cheapest. Honestly, are you suggesting that they're so bad that you can't deal with them once every year or two?
We want to take things currently with no encryption at all and put a cheap SSL cert up there so that we're not sending cleartext passwords.
I'd call $10/year for a real cert pretty damned cheap. Maybe I'm off by a factor of two -- but $20/year is still pretty damned cheap. What do you pay for hosting?
There are actually a few ways to avoid sending cleartext passwords, even over an untrusted channel, which are reasonably immune to MITM attacks -- at least, on the password itself, assuming no one did a MITM while you were creating a login.
There aren't going to be the browser clues, but an extension would solve that.
If you really can't afford $10/year, that implies you don't have a job, which implies you have a lot of time on your hands -- so you should be able to figure this out, and write the extension if needed. If you don't have that kind of time, you probably do have that kind of money. How much does Slashdot make?
Half the stuff is on shared IPs, so we couldn't even get a real cert for it
Why not simply remove those clues for self-signed sites? Why popup bigass warnings?
Because in the case where it is a bank site, you do want a giant fucking warning if someone's trying to MITM you.
The actual truth of the matter is that people don't use those clues. Half the time they don't look at their damn address bar at all.
I think you just answered your question -- this is exactly why there should be bigass warnings.
And because they don't use those clues, almost all phish attacks don't even bother with SSL, which sorta makes the whole 'people might be tricked by unsigned certs' argument look rather dumb.
The address bar now turns yellow -- green, for EV certs -- and sites like Paypal are hard at work training people to look for those signs. Why are you proposing to make that situation worse?
... that hardware is expensive and bandwidth is cheap.
No, the fundamental assumption is that bandwidth is cheap, and hardware is cheaper -- but local admin is expensive. This would mean the local machine could be locked down hard, which means much less chance for spyware -- though phishing would still be problematic.
MS absolutely can write a good program, when they need to. I would argue that the biggest problem here isn't the capability of the developers, but mismanagement and twisted priorities.
That is: Vista sucks because it is in Microsoft's best interest to have it suck in exactly the way it does. I'll leave it as an exercise to the reader to figure out exactly why this benefits Microsoft.
Upside #2 isn't necessarily true -- if the game is a typical (repetitive) MMO, it's entirely possible one could write a bot for it which doesn't need to see what's going on, only to send preset keystrokes in a preset combination.
Downsides #1 and #2 could be outsourced, though the economic implications still apply. Depending on how much more powerful computers get, these could be offset by Upside #1 -- though it still wouldn't be as profitable as the same scheme with rich clients.
Downside #3 isn't a big deal -- just give people a free trial. Bonus: Your trial will show exactly as much of the game as you want, and they can't pirate the rest.
If you run a self-signed certificate you still can get the man in the middle protection.
That is true, if and only if you have your users verify the certificate before accepting it. Which means you have to do things like, have them check the fingerprint of the certificate with you over the phone, or help them install a certificate authority, again verifying the CA's cert with a fingerprint, probably over the phone.
If your users are that savvy, they shouldn't be so frightened by the Firefox warning, and/or you should be able to walk them through disabling it.
And if you have a handful of clients you may install the root certificate in a controlled situation on the clients
In which case, Firefox 3 won't give you that warning, and this is a non-issue.
The "insecurity" of not using a well-known CA is only a commercial stunt.
The fact that you can say this tells me that you have no idea how SSL works.
Sigh...
Let's walk through this one more time, shall we?
- Your user types https://yoursite.com/
- A man in the middle intercepts, and sends back his own self-signed certificate, made out to look like yours.
- Your user clicks "Accept", because you've convinced him that the warning is only a "commercial stunt."
- A secure session is opened between your user and the man in the middle.
- The man in the middle intercepts and decrypts all traffic, then opens a session to you, using your real self-signed certificate, this time -- and forwards it along.
- You're now significantly less secure than plaintext HTTP, as the user will now get a nasty warning when the MITM stops intercepting their traffic.
- Additionally, you've trained them to accept self-signed certs from people who actually have real accounts. Over the next week, their Paypal account, bank information, and credit card details are stolen, all because you convinced them it's a "commercial stunt."
there close to a billion people on the net that wouldnt tell what to do when faced with such a disastrous looking warning as ff 3 prints out when met with a self signed ca.
GOOD. That means it's accomplished its goal much better than the popup, in which close to a billion people would have just played the game of "Which button do I click to let me into this site?"
also there are equally many people that would rather skip visiting/subscribing to a site when they see the hassle ff3 puts out.
Also good.
therefore many small service providers, businesses, communities that would not afford a decent certificate
That's bullshit -- a Godaddy certificate costs something like $10 or $20 per year. If you can't afford that, how'd you get the domain?
Now, I understand you don't like the affect -- a CA oligopoly controls the market. But if you have a better idea -- one which is actually more secure -- I'd love to hear it.
All I can think of is a web of trust, and if you can't understand the Firefox warning, what chance do you have of understanding a web of trust?
Self-signed certs are still strictly more secure that completely unencrypted traffic.
Assuming they're legitimate -- which is, you know, impossible to verify, which is the whole fucking point of a certificate authority -- to give you a means to verify that a given cert is legit.
And if they're not legitimate, depending on the site, it could be a huge warning that you're being subjected to a man-in-the-middle attack. Depending on the site, this could be much more likely.
Let me put it this way -- you go to https://www.paypal.com/, and you get a self-signed cert. Give me one good reason why the user shouldn't get a giant flashing red warning that they're probably about to be phished.
"Too lazy to unsubscribe" is completely irrelevant to this thread
I do, however, assert that it is not spam in that case. You said it:
The determination of spam is based on whether you want it to continue or not.
But you no longer seem to agree with that:
In this case it's just labeled incorrectly.
Indeed. But if I'm too lazy to unsubscribe, and hit the "spam" button again, that also implies I don't want the messages to continue -- which, by your definition, is spam.
Here's a boolean for you: Is that spam or not?
It doesn't affect the topic at hand: is spam boolean?
That question is obviously not specific enough. You appear to be arguing one of three things:
1: There is a universal definition of spam, and it is boolean. 2: Spam is defined by its subjective impact on the receiver. For a given receiver, spam is boolean. 3: Spam is defined by the label it's given. By this definition, anything Yahoo classifies as spam is, in fact, spam.
I don't think you're seriously entertaining #3. It's possible that you believe #1, which would follow from my "v14gr4" comment, but I think that would then become an overly narrow definition -- and still subjective.
Which leaves #2, which I still don't entirely agree with, since it's based on a false dichotomy. Maybe I want to continue receiving those messages, maybe I don't. Maybe I really don't care, one way or the other.
But that's the personal level. On a global level -- is there some property inherent to the email itself (if sent to multiple people) which defines it as spam or not? I'm arguing that there isn't -- that the best you can do is take a spectrum, and that's still going to be based on the subjective opinion of individuals.
Or it means you want to stop receiving them, but you're too lazy to unsubscribe.
Although classifying spam is very subjective and there are no concrete criteria for determining "spamminess", it is a boolean classification once the decision is made.
It is, however, not a definition which is common to all users. There are certain things that I like receiving notifications for, that I don't consider spam. And then there are things that other people see as perfectly alright, which I can't stand: "Send this to 10 people in the next 2 minutes and you'll meet the love of your life tomorrow!!!"
While there are things which we can all agree are spam (v14gr4), that should be the extent of the global classification system. It should not be used to block what could be legitimate email for someone else -- and it's quite possibly a UI issue that there's only one button to push, from within Yahoo Mail, to say "I don't want to get crap like this", which also means "Nobody should get crap like this."
Slashdot Mirror
Do you have to pay to watch the Olympics in China?
I don't know. Didn't we have to pay to watch them here?
Not as in "pay-per-view", but as in "over broadcast TV"?
Even if we're talking about actually-free channels (do any still exist?), there's still the matter of ad revenue. If people just put clips up on YouTube, that means Google gets the revenue, instead of the Chinese Government.
Does she even fly at all?
Customs, at least, has been known to demand the keys to a laptop, and having it obviously encrypted could delay travel significantly.
Also, there are significant problems with at least some FDE products, currently -- the "cold boot" cracks, in particular. Does she shut her laptop down every time, or only leave it on standby? Does the software actually purge the key from RAM on shutdown?
Other than that, well, do your own damned homework.
I'd suggest BitLocker, mostly because it's built-in -- kind of like, "What would you suggest for unzipping files in Windows XP?" Well, probably the "Compressed Folder" feature, right?
Under other circumstances, I'd recommend Truecrypt or dm_crypt, because you really should be using open source software for anything sensitive -- but you specifically asked for Vista, so that's fairly moot.
But I haven't done my homework.
I wish you would EXPLAIN WHY instead of just saying it is.
It falls under "hiding things from the user", which I generally consider to be bad -- and could have unpredictable results.
A contrived example: I've installed a new BB system -- or blogging engine -- whatever. I've configured everything properly, or so I think, and I'm wondering why most pages work, but certain pages just seem to hang forever.
Or, alternatively, I'm trying to access someone else's site, through a heavily restrictive censoring firewall. Again, certain pages work as intended, and certain pages hang forever, until the connection times out.
With at least some distinction in the URL scheme, I might think to myself, "Aha! These are SSL requests of some kind! Port 443 must be blocked somewhere!"
Requiring people stealing your mail to go to all that trouble, instead of letting everyone read and write on your mail and happily send it on its way with no trouble at all.
Given that all of this must be done manually -- calling the post office, intercepting the mail, physically opening the envelope, finding an identical one, and replacing it -- or opening it carefully, so as to be able to re-seal it with no evidence of tampering -- all of this requires a significant investment of time and effort, and a small investment of money.
All you're doing is requiring people to download a somewhat more sophisticated version of airpwn.
Kind of like how using rot13 is pretty pointless, for any data you actually care about. Security through obscurity, plain and simple.
Given that it's not terribly difficult, on a wireless network, to discover other people's MAC addresses, this seems like a pretty attractive attack.
I haven't actually seen that for awhile now. My DSL modem operated in bridge mode. Currently, my router -- a Linux router, which can, indeed, spoof a Mac address -- is on fiber, and has a real, live IP address. Every Linksys router I've seen lately has something called "mac clone", which is explicitly designed to spoof a Mac address -- I assume that's actually useful somewhere. (I've used it when my ISP doesn't want to let go of my DHCP lease.)
Oh, and this is at a university. When I was there, it was all a local Ethernet network -- which, in fact, was handing out live IP addresses, but it'd be worse if they didn't. The only saving grace for the RIAA was, my school required users to register their Mac addresses with an account, and that account was actually tied to their identity.
you should research browser recognition rates and 2nd year renewal charges for ssl certs before going wiseass on them.
The one I mentioned lists all sorts of browsers, everything from the major ones to "Red Hat Linux Konqueror" -- and while I can't find any extra fees for renewals, I do see discounts for renewals.
You are arguing in circles. The reason it cost that much is that Godaddy gives you your own IP and cert.
Fine. You write the scenario.
I'm on Slicehost -- that's $20/mo. IP is included. Cert is, as I've said repeatedly, $15/year. (Except when I thought it was $10/year -- sorry about that.) Insignificant next to hosting costs.
I suspect that if there was demand for it, which means it wouldn't pop warnings up all over the place, they'd give everyone SSL access, using a wildcard cert, via HTTPS, to their existing websites. For no cost.
Well, there are two options there:
Either you put everyone on a subdomain, or a subpath of the same domain -- think Freewebs -- and this might cause XSS issues...
Or you actually start handing out certs for free, without doing any background checks. That wouldn't cause giant warnings -- until the people Godaddy is reselling from invalidated their cert, and/or browsers started removing that root cert, as it's obviously not trustworthy for verifying identity.
(And you're assuming they wouldn't want to use that demand to basically print money.)
Or, you do the background checks -- but this costs money. How do you earn it back? One way is to charge people for the service of identifying them, and... hey! That's how SSL works right now.
Passports -- real, physical ones, that you use to go to other countries -- aren't free, either.
Moreover, I'm failing to see why you think that failing to see why a MitM attack would be implemented somehow demonstrates your point.
Actually, I was talking about your passive attacks.
Or, heck, just present an invalid cert, and insert a message on the cleartext webpage to click past it, and quite a lot of people would click past it.
Which is actually an argument for my point -- make the warning bigger and more obnoxious, so that people actually realize that there's a real security implication, not just another thing to click through without reading.
You have no objection except the time it would take?
Given that you're talking about implementing a whole new URI scheme, and pushing it into major browsers, I think that's a lot of time. I'm not even counting time to educate users.
Given that one of your complaints about my suggestion to "just get a real cert" is that SSL with virtualhosts isn't widely supported enough, I also don't really see the point. We've now, again, reduced the cost of real SSL to $15/year, or $1.25/month -- and that would have wider support than "httpe".
However, making it indistinguishable from plaintext is a bad idea. Making it indistinguishable from verified SSL -- or allowing the possibility for someone to confuse it with SSL -- is a much worse idea. That is what I was arguing against.
And I still don't like it. I think the benefit from it is so small (really, certs are cheap), and the implications are yet another thing which people should learn in order to be secure on the Internet, that it would be better not to have it.
And I think that, moreover, there would be a brand new meme of misinformation that your httpe is "secure enough" for whatever purpose, among people who otherwise would buy a cert, and would be better off for it. (Take rubyforge.org as a shining example of someone who already does this with self-signed certs -- though maybe I should ask and find out why they do it that way.)
But at this point, I think I'm done. After all, my browser already supports things like a fish:// URL scheme, as well as zip:/ and other fun things. People invent new URL schemes all the time -- there's steam:// for Valve products on Windows, "magnet links" for Azureus and friends...
So ultimately, my objections don't matter. Either you'll get it standardized, in which case, it'll hopefully be much more thoroughly debated (and be much improved as a result) -- or you won't, in which case, it'll be a nonstandard extension, something between you and your users, and my opinion won't really matter (kind of like Flash -- fucking Flash...)
And I notice you completely ignored the 'And we don't have infinite IPs either' point when I demonstrated that the majority of web browsers do not support them.
You've got one, right?
How many domains do you need to support, exactly?
Online businesses obviously need authentication. A guy who can barely afford godaddy to run his joomla discussion board does not.
First, Joomla? Really?
Second, why does this disqualify him from needing authentication? All you're talking about is the economic impact (which I've demonstrated as pretty small). If we're assuming he actually can run SSL, which implies that he has his own virtual host, Godaddy charges something like $40/mo for that -- an additional cert (for a plan which doesn't actually include a free one) is going to be less than $2/mo.
That doesn't mean that I can't say 'I wish the web browser would encode this password using the encryption built in, instead of something written in this annoying language'.
Javascript is actally fairly powerful, and often misunderstood, but that's beside the point. It has a builtin method for exactly what you're asking, which is called HTTP auth. You just find it ugly.
It's a frickin giant dialog box, entirely breaking the paradigm of the web.
Paradigm? I don't think that word means what you think it means...
And it really doesn't, much -- you would just be implementing exactly the same thing in an HTML form, maybe with some javascript. It has the added advantage of being uniform -- every page that uses HTTP Auth will provide the same login form.
How the heck is that 'heavy handed'? I have no problem with it.
That's a great definition of "not heavy-handed" -- "something I have no problem with." That's serious Godwinbait.
I'd be happy with a newly-defined 'httpe' or something, for encrypted but non-authenticated connections.
Fine, go ahead. I don't think it's worth the effort it'd take to implement, but that's me.
Sure, it sounds crazy, but if people see a few giant security warnings, they could quite legitimately assume everywhere there's not a warning is secure.
That actually is pretty crazy. When driving past a prison, you see giant signs that say "Do not pick up hitchhikers." Does anyone assume that hitchhikers are 100% safe everywhere else?
There are at least two orders of magnitude difference needed to log web pages, especially if you're just grabbing the headers and POST variables, and needed to read, decrypt, reencypt, and send along web pages. Especially if you have to check which are signed by a known CA and not alter them.
Are you talking about performance?
In other words, it takes a few orders of magnitude more clock cycles on my laptop when I airpwn you. What does it matter to me, as long as I have enough?
Or are you assuming that I'd be trying to crack quite a lot more connections at once? What's the motive? Where is it that I have the opportunity to intercept enough traffic that the "orders of magnitude harder" even matters -- and for what purpose do I need that much data?
I'm not trying to say "you have nothing to hide" -- what I am saying is that I don't see a scenario where such an attack would make sense -- where it would have an economic incentive, even.
Especially if you have to check which are signed by a known CA and not alter them.
Which you don't, really.
Remember, you'd have to intercept all communications. You couldn't encrypt half with one key and let the rest pass buy.
First, I only need to accept all communications from the client I'm trying to 0wn. I don't need to intercept all communications from everyone.
Second, I only need to get lucky once -- I
Not without Javascript or HTTP auth.
Right. Why is this a problem, again?
Aaaaaand....cue the personal attacks and insinuations.
This isn't personal. Minimum wage in this country is more than enough to afford $15/year for a cheap certificate. As an expense for a business, it should be minimal.
For the amount of time and effort you've put into arguing with me, at a decent wage, you could probably afford two certificates, or the same certificate for two years.
You haven't actually provided a counterargument -- you've just refused to answer it as a personal attack.
It's fine if there's no indication at all it's an encrypted connection.
Seems outside the scope of SSL. Or rather, under that scope. And as you stated above, you already have two options: HTTP auth and Javascript.
All your yammering about people being 'fooled' requires people somehow being smart enough to figure out they're on encrypted connection, and yet dumb enough to not realize it's not signed by a trusted authority.
For over a decade, there has been a lock icon in the taskbar, and https in the URL -- and we've been training users to look for these signs. A green address bar is nice, yes, but what you're proposing is that we completely retrain users to look for completely different clues for "this is an encrypted connection that I trust" and "this is just some random encrypted connection".
That, or you're proposing that we hide the crypto from users entirely -- which seems just as heavy-handed as throwing up gigantic warnings. So much for wanting choice.
(Which, despite what people seem to think, actually is a hell of a lot easier than MitMing a connection.)
Seems you didn't actually have a counter for my airpwn link.
Give me one situation where someone would "trivially snoop on a connection" without also being able to trivially run an SSL MITM attack, and trivially snoop on your wish-it-was-SSL connection.
For one, *I don't CARE* about MITM attacks - they are 10000 times harder to pull off than basic wireless or ethernet snooping at a hotel, Internet cafe, or on a LAN.
Maybe so, but I don't have to, because someone else already has. Downloading Wireshark and downloading Airpwn are equally trivial. Implementing Wireshark is probably harder than implementing Airpwn, but that's really irrelevant.
And if your attitude becomes common, how soon before the same kinds of automated passive attacks are replaced with automated active attacks?
If I wanted to be treated like I'm stupid and prevented from doing things that I want to do because a browser thinks it would be better that way, then I'd use IE.
Major difference: IE won't give you a choice. If you feel so strongly about this behavior in Firefox, go patch it. Or, if you're not a developer (or feeling particularly lazy), file a bug asking for the ability to turn this off, or troll around looking for people willing to fork the browser.
For what it's worth, even SSH behaves like this. If you SSH to a host which is unknown, you'll get a big ugly warning -- and it will then keep track of that host key. If you SSH to a host whose key has changed, you will get a GIANT ERROR, which in BIG SCARY CAPS tells you that it's possible someone's intercepting your traffic RIGHT NOW OMG!
And there is no way to override it short of removing the key manually from the config file -- which is a good deal harder than four clicks.
I would think SSH is the kind of tool power users would be using for themselves. It's the kind of place you would expect people to be well-educated about this sort of thing, and where you'd expect people to not want their decisions made for them.
But they chose to make it difficult to be insecure.
Do you check the signatures on your browser every time you install it or update it to make sure the upstream source wasn't tampered with?
Actually, yes. Specifically, apt uses GPG to check them. Every install, every update -- of every app on the system. I therefore open myself up to a MITM exactly once -- when I download the install CD.
Do you check your keyboard plug every time you sit down at your desktop to make sure there isn't a logger on it?
Actually, I carry my keyboard with me. Not for security reasons, but it does kind of make this moot.
Do you cover your keyboard everytime you enter your password to make sure nobody is watching?
No. I do, however, use Dvorak, and type extremely fast. Someone would have to be watching very carefully, or recording it to play back at a slower speed. And that password is only used locally -- the passwords I use remotely, I mostly have my browser memorize, or they're keys instead of passwords -- so they would have to steal my machine in order to do it.
In the case of my laptop, they would also have to steal my USB key, or they'd have to very, very quickly perform a cold-boot exploit.
There are thousands of potential vulnerabilities that exist every time you use your computer
I don't see that as a reason to introduce more.
quit making it out like it's worthless without authentication - it's not.
Actually, it kind of is. Without authentication, it is security through obscurity -- you're basically praying that no one who is capable of sniffing your packets realizes that they could probably alter them, too.
Now, by some arguments, it's not completely useless. After all, neither is the "two-factor authentication" employed by most banks -- since it is theoretically possible that someone would collect your password, but not the answer to your security question.
But the payoff is so low, at this point, that I don't see why you'd bother -- and I think it's dangerous to support it at all, because it provides a false sense of security.
It's like listening to people for whom English is a second language
I work with a somewhat-accented Indian guy, and I can tell you, he is much easier to listen to than some of these comments.
Well I was going to until I saw how you spelled "pursuit"
Well, damn, you caught me. But given that it was in the same breath as "happyness", I should be alright.
While I'm at it, found someone else for $14.95:
http://www.trustico.com/products/rapidssl/rapidssl.html
If that's your argument, it's pretty pathetic. A quick Google for "Cheap SSL", and within the top ten results is another provider who's under $30/year. Found another at $25/year. A few others are at $60/year -- that's $5/mo.
Godaddy is still the cheapest. Honestly, are you suggesting that they're so bad that you can't deal with them once every year or two?
We want to take things currently with no encryption at all and put a cheap SSL cert up there so that we're not sending cleartext passwords.
I'd call $10/year for a real cert pretty damned cheap. Maybe I'm off by a factor of two -- but $20/year is still pretty damned cheap. What do you pay for hosting?
There are actually a few ways to avoid sending cleartext passwords, even over an untrusted channel, which are reasonably immune to MITM attacks -- at least, on the password itself, assuming no one did a MITM while you were creating a login.
There aren't going to be the browser clues, but an extension would solve that.
If you really can't afford $10/year, that implies you don't have a job, which implies you have a lot of time on your hands -- so you should be able to figure this out, and write the extension if needed. If you don't have that kind of time, you probably do have that kind of money. How much does Slashdot make?
Half the stuff is on shared IPs, so we couldn't even get a real cert for it
Most clients support SSL for a virtual host by now.
Why not simply remove those clues for self-signed sites? Why popup bigass warnings?
Because in the case where it is a bank site, you do want a giant fucking warning if someone's trying to MITM you.
The actual truth of the matter is that people don't use those clues. Half the time they don't look at their damn address bar at all.
I think you just answered your question -- this is exactly why there should be bigass warnings.
And because they don't use those clues, almost all phish attacks don't even bother with SSL, which sorta makes the whole 'people might be tricked by unsigned certs' argument look rather dumb.
The address bar now turns yellow -- green, for EV certs -- and sites like Paypal are hard at work training people to look for those signs. Why are you proposing to make that situation worse?
... that hardware is expensive and bandwidth is cheap.
No, the fundamental assumption is that bandwidth is cheap, and hardware is cheaper -- but local admin is expensive. This would mean the local machine could be locked down hard, which means much less chance for spyware -- though phishing would still be problematic.
MS absolutely can write a good program, when they need to. I would argue that the biggest problem here isn't the capability of the developers, but mismanagement and twisted priorities.
That is: Vista sucks because it is in Microsoft's best interest to have it suck in exactly the way it does. I'll leave it as an exercise to the reader to figure out exactly why this benefits Microsoft.
Upsides #1 and #3 already exist for MMOs.
Upside #2 isn't necessarily true -- if the game is a typical (repetitive) MMO, it's entirely possible one could write a bot for it which doesn't need to see what's going on, only to send preset keystrokes in a preset combination.
Downsides #1 and #2 could be outsourced, though the economic implications still apply. Depending on how much more powerful computers get, these could be offset by Upside #1 -- though it still wouldn't be as profitable as the same scheme with rich clients.
Downside #3 isn't a big deal -- just give people a free trial. Bonus: Your trial will show exactly as much of the game as you want, and they can't pirate the rest.
No, it's just a gigantic greenhouse ship.
I really don't support anyone that says paying through the roof for a trusted certificate is better than a self-signed certificate.
$10/year is not "through the roof" by any stretch.
This also makes rush/trial/beta setups very annoying
It's possible to route a beta to example.com/beta, but I realize most developers aren't competent enough to do that. (Relative URLs, people!)
So, next best thing, why not beta.example.com? Or staging.example.com? Or tell them not to put anything secure into it, and disable the SSL.
This isn't rocket surgery, people.
If you run a self-signed certificate you still can get the man in the middle protection.
That is true, if and only if you have your users verify the certificate before accepting it. Which means you have to do things like, have them check the fingerprint of the certificate with you over the phone, or help them install a certificate authority, again verifying the CA's cert with a fingerprint, probably over the phone.
If your users are that savvy, they shouldn't be so frightened by the Firefox warning, and/or you should be able to walk them through disabling it.
And if you have a handful of clients you may install the root certificate in a controlled situation on the clients
In which case, Firefox 3 won't give you that warning, and this is a non-issue.
The "insecurity" of not using a well-known CA is only a commercial stunt.
The fact that you can say this tells me that you have no idea how SSL works.
Sigh...
Let's walk through this one more time, shall we?
- Your user types https://yoursite.com/
- A man in the middle intercepts, and sends back his own self-signed certificate, made out to look like yours.
- Your user clicks "Accept", because you've convinced him that the warning is only a "commercial stunt."
- A secure session is opened between your user and the man in the middle.
- The man in the middle intercepts and decrypts all traffic, then opens a session to you, using your real self-signed certificate, this time -- and forwards it along.
- You're now significantly less secure than plaintext HTTP, as the user will now get a nasty warning when the MITM stops intercepting their traffic.
- Additionally, you've trained them to accept self-signed certs from people who actually have real accounts. Over the next week, their Paypal account, bank information, and credit card details are stolen, all because you convinced them it's a "commercial stunt."
there close to a billion people on the net that wouldnt tell what to do when faced with such a disastrous looking warning as ff 3 prints out when met with a self signed ca.
GOOD. That means it's accomplished its goal much better than the popup, in which close to a billion people would have just played the game of "Which button do I click to let me into this site?"
also there are equally many people that would rather skip visiting/subscribing to a site when they see the hassle ff3 puts out.
Also good.
therefore many small service providers, businesses, communities that would not afford a decent certificate
That's bullshit -- a Godaddy certificate costs something like $10 or $20 per year. If you can't afford that, how'd you get the domain?
Now, I understand you don't like the affect -- a CA oligopoly controls the market. But if you have a better idea -- one which is actually more secure -- I'd love to hear it.
All I can think of is a web of trust, and if you can't understand the Firefox warning, what chance do you have of understanding a web of trust?
Self-signed certs are still strictly more secure that completely unencrypted traffic.
Assuming they're legitimate -- which is, you know, impossible to verify, which is the whole fucking point of a certificate authority -- to give you a means to verify that a given cert is legit.
And if they're not legitimate, depending on the site, it could be a huge warning that you're being subjected to a man-in-the-middle attack. Depending on the site, this could be much more likely.
Let me put it this way -- you go to https://www.paypal.com/, and you get a self-signed cert. Give me one good reason why the user shouldn't get a giant flashing red warning that they're probably about to be phished.
"Too lazy to unsubscribe" is completely irrelevant to this thread
I do, however, assert that it is not spam in that case. You said it:
The determination of spam is based on whether you want it to continue or not.
But you no longer seem to agree with that:
In this case it's just labeled incorrectly.
Indeed. But if I'm too lazy to unsubscribe, and hit the "spam" button again, that also implies I don't want the messages to continue -- which, by your definition, is spam.
Here's a boolean for you: Is that spam or not?
It doesn't affect the topic at hand: is spam boolean?
That question is obviously not specific enough. You appear to be arguing one of three things:
1: There is a universal definition of spam, and it is boolean.
2: Spam is defined by its subjective impact on the receiver. For a given receiver, spam is boolean.
3: Spam is defined by the label it's given. By this definition, anything Yahoo classifies as spam is, in fact, spam.
I don't think you're seriously entertaining #3. It's possible that you believe #1, which would follow from my "v14gr4" comment, but I think that would then become an overly narrow definition -- and still subjective.
Which leaves #2, which I still don't entirely agree with, since it's based on a false dichotomy. Maybe I want to continue receiving those messages, maybe I don't. Maybe I really don't care, one way or the other.
But that's the personal level. On a global level -- is there some property inherent to the email itself (if sent to multiple people) which defines it as spam or not? I'm arguing that there isn't -- that the best you can do is take a spectrum, and that's still going to be based on the subjective opinion of individuals.
Flag as spam clearly means it's spam
Or it means you want to stop receiving them, but you're too lazy to unsubscribe.
Although classifying spam is very subjective and there are no concrete criteria for determining "spamminess", it is a boolean classification once the decision is made.
It is, however, not a definition which is common to all users. There are certain things that I like receiving notifications for, that I don't consider spam. And then there are things that other people see as perfectly alright, which I can't stand: "Send this to 10 people in the next 2 minutes and you'll meet the love of your life tomorrow!!!"
While there are things which we can all agree are spam (v14gr4), that should be the extent of the global classification system. It should not be used to block what could be legitimate email for someone else -- and it's quite possibly a UI issue that there's only one button to push, from within Yahoo Mail, to say "I don't want to get crap like this", which also means "Nobody should get crap like this."
Oh, sorry, for a moment, I'd confused this with newsgroups. When you mentioned HTTP, it helped -- I still think of those as "RSS feeds".