Yeah, there are all sorts of things that people should do that take a week-long class, and yet never seem to do them.
I wish we'd spend a semester in high school having classes on this. A week on computer maintenance, a week on car maintenance, a week on house maintenance, a week on money management, a week covering the dozen or so different scams con artists use and how to spot them, a week on cooking, etc.
Yes, some of those rightly fall under optional entire classes that people can take. And I'm sure people who've taken those classes can coast through that week, or, hell, we could even let them just skip that week.
The point is that everyone should have basic knowledge of a wide range of things they are going to need to be able to do. At least enough knowledge to recognize that they don't have knowledge about something. Where people end up thinking 'Hey, this car requires maintenance, and I've forgotten what they told in me in HS that I need to do.I should check the manual.' instead of just blithely traveling along until their car explodes because their oil is entirely make of grit.
I'm sure most slashdot readers have read that 'incompetent people cannot just their own competence' paper. We need to at least raise people to the level that they recognize that a) something is wrong, b) they should try looking that thing up to see if there's some obvious solution, and c) if not, ask for help.
Way too many people never notice 'a' on their computer until much too late, and then just immediately to 'c'. Same with cars, and other stuff.
Of course, as long as we judge entirely by 'standardized testing', school don't have time to spend on that stuff.
But anyway, barring a class, there are some very nice simple computer reference and troubleshooting books out there. People should buy them, just like they should buy one of the 'disassemble and reassemble' book of their car. Yeah, they'll need it exactly five time in the life of the car...but they will need it.
It saves them money the very first time they discover that their monitor won't turn on, and they read they not only need to check the power connection at the wall (Which they should already know), but that they also need to check the power connection at the monitor, as sometimes those can be unplugged, and the connection to the computer because it will go into power-save mode if that's disconnected....instead of calling some tech guy to do it for them.
Yeah, a while back, when video recording equipment first got small and cheap enough for people to purchase, scum started using it to spy on women. This was back in the 80s and 90s, and it turned out while there were laws against recording conversations, which could be legally used to nail some of them, if they recorded just video (Which all of them immediately started doing.), there was actually no law against it.
But that was back in the 80s and 90s, and there were enough well-publicized cases of this happening that they changed the law.
Actually, this is a much more serious offense than being a peeping tom.
Peeping tom laws really only kick in when all your behavior is otherwise legal, but you're violating someone's privacy, like climbing a tree on public property to see in a window. (And people don't realize how vague trespassing can be, so even if they're on that person's property it can be hard to prove 'trespassing'.)
Installing spying software, and causing recordings to be made, is just outright illegal in the first place, even if he didn't use it for the purpose he used it for.
News for Really Dumb Nerds: Rest of internet uses same DNS system as web pages, not some magical other system to look up domain names.
This flaw, if it exist, is more dangerous for email and FTP. Because those automatically log in, and thus attackers can just wildcard all domains to a password collection server.
Unlike web sites, where you have to mimic each individual website, or built a complicated pass-through, to get people to log in. (Or attempt to steal cookies, which has its own problems.)
I realized that about two minutes after I read about the flaw.
The hrefs all went to the same place, from the spam I saw, and it was a somewhat 'legit' looking URL, not IP address or spam keywords in it, so until spamassassin knows about that specific one, it's rather moot.
Speaking of that, is there anyone, now that SAREs is not updating (I notice you use them, I do too), that's providing good rules?
Also, my spamassassin doesn't do RBLs and RHSBLs...simply because I use postfix's policyd-weight and nothing that triggered on both spamcop and the XBL would make it to spamassassin.:)
Yeah, spamassassin will eventually train itself if it keeps getting near-identical messages from spam sources.
But the first wave will get through.
This is why greylisting to everywhere but spamtraps is a good idea. Let the spamtrap spam in, feed it directly to spamassassin, and even if the greylists get past, by then spamassassin's catching it.
Alternately, there's razor and pyzor, but I honestly don't know much about that.
Dude, spamassassin didn't recognize that message as spam.
DNS_FROM_OPENWHOIS, HELO_DYNAMIC_DHCP, RCVD_IN_BL_SPAMCOP_NET, RCVD_IN_PBL,RCVD_IN_XBL, and RDNS_NONE are origin checks, not message checks. (Well, the helo isn't technically, but forging it would be worse than correctly stating the dynamic IP.)
According to the message checks, that message scored BAYES_50=0.001 and HTML_MESSAGE=0.001 using standard spamassassin checks, and SARE_MONEYTERMS=0.681 from the very nice SAREs checks that smart mail admin install. That is almost certainly not enough to mark it as spam. And the 'money terms' probably triggered by sheer chance, considering this thing is scraping CNN.com for headlines. Other messages sent by this thing probably wouldn't trip over that.
The reason it was blocked was that it came from an IP that was current blacklisted for spamming and was clearly a dynamic IP, not that spamassassin recognized the message. Any mail from that IP would have been blocked. Spamassassin actually fell down pretty badly on the content analysis.
Any company that considers its proprietary information to be private should have a hard time arguing with that. And it's easy enough to demonstrate to management bozos how trivial it is to sniff passwords off the wire.
Ah, but this isn't a single company. We're webhosts for a dozen or so businesses, and a few cheap local non-profits, in addition to running our own websites and storefronts.
Company computers are set up with encryption. (At least since I discovered that no one else was using it.) It's the other guys who aren't.
But your idea isn't a bad one. I need to figure out if I can determine from the logs who's using TLS over standard ports (I know I can see who's using SSL ports.) and start talking about a 'security upgrade' that will, sadly, require certain people to fix their email clients.
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.
Godaddy doesn't have to hand out the certs they use. They simply have to set up a listening server on port 443 with the same virtual domain setup they have, and put a * cert on that.
However, making it indistinguishable from plaintext is a bad idea.
I wish you would EXPLAIN WHY instead of just saying it is. Just asserting things does not make them true.
An encrypted connection without authentication should be trusted, by the end user, as much as plaintext. I'll accept that. (1)
So how is making indistinguishable from plaintext a bad thing?
1) Although I will still argue that the system as a whole is much more secure from outside tampering, in the same way that sealed envelopes are more secure than postcards, despite the fact that almost anyone can file a change of address form at a post office or steal from their mailbox and intercept someone's mail, open the envelopes, and replace them in the end mailbox after tampering. 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.
This is the sort of thing we could have with opportunistic encryption using IPsec.
The problem with IPsec is, frankly, it is never going to actually happen.
And the problem with SSL is that there's no protocol-level independent generic 'negotiation'. It really really should have been designed to start plaintext and switch over, which would have allowed magically building it into every TCP server. TLS is designed to switch over, but not in a protocol independent way, so that's even more annoying.
I recognize that that's the status quo, but it's easy enough to fix. Admins just need to disable the cleartext ports and publish instructions for their users (not necessarily in that order;^). Every one of my mail users uses IMAPS, because port 993 is the only protocol available. And even if they were to muck up the client config by changing the port to 993 without checking the SSL/TLS box, they wouldn't be able to get to the point of sending IMAP credentials in the clear, because the IMAP client won't be able to read a server hello.
Ha, I wish I had as much authority over my server as you. There's no way I could justify breaking everyone's mail connection...again.
I have actually done something like this once, I stop accepting mail submissions on port 25 and made everyone use the smtp submission port. (And the stupid smtps submission port) I was able to justify that because about every month someone would call and tell me 'the mail server was broken', when in fact they were on a new connection, or their ISP had just started, to block port 25. And I eventually said to hell with it and made everyone switch off 25 at once, as I was able to convince my company that, eventually, the amount of problems using port 25 was causing outweighed the amount of problems switching it off all at once would cause.
I doubt I can use the same logic for unencrypted connections. If it's not broken don't fix it is the motto at most companies, and definitely don't fix it in a way that breaks current setup for people.
Meanwhile, I run SSL ports, if anyone uses them, and I have TLS switching on my main ports. Which means if anyone's bothered to click any security setting, or the client does TLS by default, it's encrypted.
Except that it is less secure than an unencrypted site. The reality is, if a user goes to a fraudulent copy of their bank's site, and it has an SSL certificate which is self signed, it SHOULD tell the user that the site may not be passing itself off as what it claims to be.
I don't know in what universe self-signed sites are less secure than unencrypted ones, or even how that's supposed to work. I can't even imagine how you can be less secure than unencrypted.
About a dozen on the server I've got could reasonable benefit from an encrypted, in that they have moderately sensitive information passing over them. Any CMS, for example, has at least an admin interface.
First, Joomla? Really?
And your ideal CMS is...?
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.
You are arguing in circles. The reason it cost that much is that Godaddy gives you your own IP and cert.
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. (Heck, it wouldn't cost them anything.)
In fact, thanks for that example, I think it just demonstrated my point for me better than I ever could.
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.
And neither do I. Moreover, I'm failing to see why you think that failing to see why a MitM attack would be implemented somehow demonstrates your point.
Normal human beings are not subject to MitM attacks that SSL would protect them against. They really aren't.
Moreover, if they are, either they're going to fall for it regardless, or they're not going to fall for an unauthenticated connection that look sufficiently different from an authenticated one.
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 only need to be faster than the DNS server for one response -- or, for that matter, the DHCP server. After that response, the client will connect directly to me.
If you are talking about targeted attacks, my point about encryption makes more sense. Because people use the same passwords all over the place. A single cleartext login and you've won.
Moreover, as I've repeatedly pointed out, if you're going to MitM someone with a targeted attack and editing web pages, the logical thing to do is to simply set up a real SSL server with a similar name to the bank, and replace the links in the banks cleartext webpages to that place.
Or just don't use any SSL at all.
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.
I'm not sure why having the option to have unauthenticated encrypted connections helps any of those in the slightest.
I'm arguing that in a context where one might be expecting security, we shouldn't pretend something is more secure than it is. And I'm arguing that when there's a finite amount of development time to be spent improving browsers, I'd much rather it be spent on things like the HTML5 video tag, SVG, standards compliance, Javascript performance, etc, rather than on making mediocre security easier.
That's it. That's where you're at. You have no objection except the time it would take?
I mean that every protocol has to define a unique way to start TLS negotiation: LDAP sends a particular OID, SMTP uses STARTTLS, IMPP uses a tag, etc. Then the protocol has handle various failures gracefully.
Yeah, I agree. That's why I wish the telnet negotiation protocol itself had included SSL, enabling essentially all line-mode TCP/IP connections to switch to SSL on the fly.
Then we could have avoided all this silliness. All connections start plaintext, all of them switch to SSL without sending a single byte in-band. (Except if it needs to, like HTTP.)
That way it could be, like you say, a layer on top of the application. You'd probably get it free with sockets in libc. Stick a flag on the socket when you make it, and it only accepts SSL.
(Even better, of course, would have been, instead of inventing SSL, invent something that works like SSL entirely at the telnet negotiation level, where all connections are just 'plaintext SSL' connections, and to go encrypted, you just change the encryption used. But I don't know the history well enough to know if that would have been possible.)
Furthermore, SSL's being a mixed binary and ASN.1 protocol makes it very squirrelly when a line-based protocol such as IMAP or SMTP switches it on. At best, it's, shall we say, aesthetically displeasing.
No kidding. That's probably the worse method possible.
I know what you're saying about multiple ports being better than single 'upgradable' ports, and in a way they are, but having two ports means every piece of software in existence defaults to the unencrypted one.
So while you talk about hypothetical misconfigured software that someone failed to check 'Don't connect if cannot secure the connection', what's actually going on is that almost none of the population is using SSL ports at all. Their mail client defaulted to the standard ports, and it worked. If that port offers encryption, the mail client will upgrade, but it's not going to randomly look for the encrypted port.
I know this for a fact. I've been running a mail server for years, and it's moved between machines. Once, when I moved the mail server but not the webmail that was using the same domain name, I had to forward the IMAP and POP3 port to the new server, and I had already pointed my client there to test, so failed to notice I forgot to forward the SSL ports...for two weeks. No one even noticed. Out of forty or so people, not a single one was using an encrypted connection, not a single one complained their email stopped working. I only caught it when I fixed my client to use the old server name and couldn't connect.
SSL ports are only 'more secure' if there's a set of people who would go around setting up their client to use that port, but not setting up their client to require encrypted connections. I suspect this set of people does not, in fact, exist, and even if it does, it is vastly outnumbered by the people who just accept the defaults if everything works.
Within a year or so, hopefully, virtually hosted SSL sites will be commonplace.
Not until IE7 on XP supports it. For some reason, IE7 does on Vista, but not XP. Despite what MS likes to pretend, XP will be around a long time.
This wouldn't be possible in the switching system you advocate for.
Sure it would. The telnet protocol allows both ends to specify requirements, and results in a disconnect if the other end doesn't support it. (In fact, it appears to already support SSL, but I suspect that doesn't include certs.)
Granted, the client could lie, but that would be a protocol violation, and if we're considering those, nothing stops a client from spewing plaintext into a SSL connection either.
That said, the problem there is poorly designed protocols that allow one greeting unparsed message from the server and then the client instantly sends the login. This was yet another protocol stupidity, right up there without allowing switching to SSL via telnet negotiation. (Although if we'd used the latter, we wouldn't have worry about the former...telnet negotiation happens before any communications at all.)
SMTP, interestingly, doesn't have this problem, because SMTP wasn't designed with authentication in the first place. The server has to state the ability to login, via ESMTP options. IMAP, being a late designed protocol, doesn't have this problem either.
With both IMAP and SMTP, you connect, and get a message from the server, but that message has to state the various methods you are allowed to login.(Along with various other options.) The server can, in fact, state no login methods at all, and just present the 'I can switch to SSL' option. After the switch, it can present the login methods again.
Furthermore, a switching system entangles application protocols with the constantly mutating TLS, which would make maintenance of both more difficult.
I don't know what you mean by that. SSL negotiates itself quite well between different versions. A lot of SMTP traffic already magically switches itself to SSL. I myself have let my mail server switch to SSL (Well, TLS) on demand, and have had over 500 TLS connections the last two days. (Which is actually absurdly high for the amount of mail we get, so either spammers are using SSL or my grep failed.)
Although obviously, looking at it from that direction is stupid. Our mail server (postfix) also attempts to negotiate SSL connections for outgoing mail, and I've never seen mail bounce because it couldn't negotiate a connection.
Certificates change regularly for legitimate reasons. I see no reason to confuse users by alerting them when this happens.
Let me restate: Users should be alerted when an self-signed cert changes to another self-signed cert, or when a CA-signed cert changes to a self-signed cert.
Yes, what specific problem are you talking about? HTTP is for anything that doesn't require a secret (mod Digest auth); HTTPS is for everything else. What's the problem?
The problem is that negotiation happens before any other communications, so that clients cannot state what website they are actually connecting to, so the server cannot present the correct certificate for that web site. Which is why HTTPS sites need their own IP.
This actually would be a problem in other protocols, except no email client expect signed-by-the-email-domain in email SSL connections.
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.
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.
IP addresses are not free.
And I've already pointed out we're not talking about businesses. Online businesses obviously need authentication. A guy who can barely afford godaddy to run his joomla discussion board does not.
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.
Yes, and I use Javascript.
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'. Public key encryption in Javascript is incredibly annoying.
HTTP auth would be an option, and this is actually what it's designed for, if it wasn't the ignored step-child of web browsers. It's a frickin giant dialog box, entirely breaking the paradigm of the web. Why they can't give a login bar along the top of the page and print the 'error' page under it, I don't know.
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.
How the heck is that 'heavy handed'? I have no problem with it.
If you're really that worried about 'https' in the URL bar, I'd be happy with a newly-defined 'httpe' or something, for encrypted but non-authenticated connections. Or a yellow warning bar that the page's origin cannot be verified.
Anything but the big pop-up implication that there's some huge security issue when someone goes from plaintext to unsigned SSL, requiring four or five clicks to get past.
Incidentally, I suspect that's some of what's causing the actual security issue of people trusting random web sites, in that people think plaintext browsing is somehow secure and people can't lie about their origin. 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.
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.
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.
There's a reason that Comcast wasn't altering torrent connections to disconnect them, and was instead sending TCP reset packages...it couldn't operate fast enough to actually edit the connections in situ. They're actually statistically sampling the connections because they can't handle the volume, and their system was operating from a copy of actual traffic, not 'in line'.
Remember, you'd have to intercept all communications. You couldn't encrypt half with one key and let the rest pass buy.
You're arguing just because something isn't technically impossible for an attacker to break means we shouldn't allow it. That's just crazy talk. We allow all sorts of 'moderate security' in the computer industry, a lot of actually aimed at passive spying, like logins for mail and http auth, which anyone could MiTM, and storefront software that doesn't store entire CC numbers, despite anyone being able to alter it to do that very quickly.
Saying 'Ha ha, anyone can MiTM, and asking for a security ability that can be defeated by it is stupid' is just security elitism. We're asking for 'wearing a badge' security, not 'fingerprint and r
I disagree. With STARTTLS, it's much easier for a misconfigured client to send credentials in the clear. Server policy may prevent those credentials from being honored before TLS establishment, but by then they've already been exposed.
Yes, it's easy for a misconfigured client to do almost anything. I mean, type the wrong domain name in, and who knows where it will send your credentials!
However, if the system had been set up to switch automatically from the start, correctly configured servers and any clients that supported SSL could switch automatically. Without any prompting or 'configuration'. If the client and server support SSL, they'd negotiate it in the connection. If one of them didn't...well, you're insecure no matter how you're configured.
Whereas, with a two port system, all clients are going to default to the unencrypted port, which means they will have no security at all. Which in actual fact is a good 95% of POP3 and IMAP users out there. They selected POP3 or IMAP, and got port 110 or 143, and that's it. (1)
And, of course, nothing would stop clients from offering a 'refuse to send credentials until encrypted' toggle. Although a more logical default, especially for mail clients, would just be to store a cert, for each connection, when they get it, and warn if it changes.
I'm not sure what problems you think having TLS-wrapped port designations causes.
Well, um, there's exactly what we're talking about, with HTTPS connections.
1) Of course, a lot of server scramble the login, but reading other people here talking about unauthenticated HTTPS, we are apparently required to assume there are dozens of MitM attempting to hijack our connections, and any 'security' that doesn't protect against that is no security at all and not worth doing. So obviously scrambled passwords are a scam...MitM can just hijack your IMAP connection, or whatever, and keep it open forever.
Well, the whole thing is set up stupidly in the first place.
The entire concept of secured-from-the-start SSL on another port was incredibly stupid. It happened with POP3, IMAP, HTTP, etc, and has caused nothing but problems.
Writing all protocols where you first connect in plaintext, and then switch to an encrypted connection, would have been infinitely more sensible.
Especially since, if we'd done it then, we could have had a OOB character defined to do that and everyone could have done it the same way. I.e, it should have been part of the 'telnet' protocol.(Yes, yes, that's not actually the 'telnet' protocol, but you know what I mean.)
Everyone's switching over now, with things like STARTTLS and the new virtual hosts for HTTPS (I believe that starts unencrypted and sends the hostname, and then flips to encrypted, but I could be wrong.), but there are always going to be clients out there that can either speak plaintext or SSL, not start plaintext and switch, so the SSL ports will be around for a long time.
Hell, I still have to run a damn encrypted 'smtps' port on 465 on my mail server, for Outlook Express, because it can't connect to the standard submission port and send STARTTLS.
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.
Not without Javascript or HTTP auth.
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?
Aaaaaand....cue the personal attacks and insinuations.
As it so happens, I do have a job, and part of that job is to run an web server with some SSL storefronts. It also runs a lot of Joomla community sites that have a slight amount of security would be nice.
Most clients support SSL for a virtual host [wikipedia.org] by now.
'Most clients', of course, not including IE6 or IE7 on XP. Which by themselves occupy >50% of the web browsing traffic. (And while half the remainer might be using more advanced browsers, the other half is using less.)
Because in the case where it is a bank site, you do want a giant fucking warning if someone's trying to MITM you.
If someone is trying to MitM your bank, you know what he'll do? He just won't use SSL.
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?
What the hell are you talking about? I said to not provide the clues for self-signed certs. People who know about the clues thus won't be fooled. People who don't know about the clues are already fooled by simply not using SSL.
I swear, people like you are so goddamn annoying. Everyone pushing for not having big warnings about self-signed certs is fine if browsers don't put up lock icons and green bars and everything, and we've been saying this from the start. It's fine if there's no indication at all it's an encrypted connection.
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. So you imagine a world where web browsers treat CA-signed and self-signed certs exactly the same, despite that being obviously fucking stupid and not what anyone is suggesting. Web browsers can indicate it however they want, or not at all, as long as they don't run around implying it's somehow less secure, and requires more work, than plaintext browsing.
We are simply suggesting that we be allowed to encrypt web pages, with no authentication, if we so choose, without bigass warnings popping up scaring everyone, so people can't trivially snoop on a connection and get passwords. (Which, despite what people seem to think, actually is a hell of a lot easier than MitMing a connection.) That is all.
No, I mean, trusting the proxy would present all SSL sites as authenticated...even ones that weren't, or were clearly the wrong name, or expired, or even revoked.
Mod parent up. This is exactly what everyone's been saying.
Although I won't mind a little yellow bar at the top of the page that notifies you that the cert has been saved and lets you mark it as trusted or remove it or whatever.
Yeah, and if FF popped up a message explaining that the website had presented a way to contact the same site securely in the future, although this did not confirm who they were, and ask 'if you want to store this code for the future, or just for this session, or not visit at all', that would be one thing.
Messages implying that it's somehow less secure than normal unencrypted web pages are another thing. Warning users, in big error pages and with sinister sounding warnings, when you are at least as secure as the dozens of unencrypted pages they visit every day, is just absurd.
Slashdot Mirror
Nothing 'technically' about it. It is treason.
No one should be seeking putative damages.
Companies that have knowingly promoted defective voting systems should be disbanded, and their executives tried for treason.
Yeah, there are all sorts of things that people should do that take a week-long class, and yet never seem to do them.
I wish we'd spend a semester in high school having classes on this. A week on computer maintenance, a week on car maintenance, a week on house maintenance, a week on money management, a week covering the dozen or so different scams con artists use and how to spot them, a week on cooking, etc.
Yes, some of those rightly fall under optional entire classes that people can take. And I'm sure people who've taken those classes can coast through that week, or, hell, we could even let them just skip that week.
The point is that everyone should have basic knowledge of a wide range of things they are going to need to be able to do. At least enough knowledge to recognize that they don't have knowledge about something. Where people end up thinking 'Hey, this car requires maintenance, and I've forgotten what they told in me in HS that I need to do.I should check the manual.' instead of just blithely traveling along until their car explodes because their oil is entirely make of grit.
I'm sure most slashdot readers have read that 'incompetent people cannot just their own competence' paper. We need to at least raise people to the level that they recognize that a) something is wrong, b) they should try looking that thing up to see if there's some obvious solution, and c) if not, ask for help.
Way too many people never notice 'a' on their computer until much too late, and then just immediately to 'c'. Same with cars, and other stuff.
Of course, as long as we judge entirely by 'standardized testing', school don't have time to spend on that stuff.
But anyway, barring a class, there are some very nice simple computer reference and troubleshooting books out there. People should buy them, just like they should buy one of the 'disassemble and reassemble' book of their car. Yeah, they'll need it exactly five time in the life of the car...but they will need it.
It saves them money the very first time they discover that their monitor won't turn on, and they read they not only need to check the power connection at the wall (Which they should already know), but that they also need to check the power connection at the monitor, as sometimes those can be unplugged, and the connection to the computer because it will go into power-save mode if that's disconnected....instead of calling some tech guy to do it for them.
Yeah, a while back, when video recording equipment first got small and cheap enough for people to purchase, scum started using it to spy on women. This was back in the 80s and 90s, and it turned out while there were laws against recording conversations, which could be legally used to nail some of them, if they recorded just video (Which all of them immediately started doing.), there was actually no law against it.
But that was back in the 80s and 90s, and there were enough well-publicized cases of this happening that they changed the law.
Actually, this is a much more serious offense than being a peeping tom.
Peeping tom laws really only kick in when all your behavior is otherwise legal, but you're violating someone's privacy, like climbing a tree on public property to see in a window. (And people don't realize how vague trespassing can be, so even if they're on that person's property it can be hard to prove 'trespassing'.)
Installing spying software, and causing recordings to be made, is just outright illegal in the first place, even if he didn't use it for the purpose he used it for.
No shit.
News for Really Dumb Nerds: Rest of internet uses same DNS system as web pages, not some magical other system to look up domain names.
This flaw, if it exist, is more dangerous for email and FTP. Because those automatically log in, and thus attackers can just wildcard all domains to a password collection server.
Unlike web sites, where you have to mimic each individual website, or built a complicated pass-through, to get people to log in. (Or attempt to steal cookies, which has its own problems.)
I realized that about two minutes after I read about the flaw.
The hrefs all went to the same place, from the spam I saw, and it was a somewhat 'legit' looking URL, not IP address or spam keywords in it, so until spamassassin knows about that specific one, it's rather moot.
Speaking of that, is there anyone, now that SAREs is not updating (I notice you use them, I do too), that's providing good rules?
Also, my spamassassin doesn't do RBLs and RHSBLs...simply because I use postfix's policyd-weight and nothing that triggered on both spamcop and the XBL would make it to spamassassin. :)
Yeah, spamassassin will eventually train itself if it keeps getting near-identical messages from spam sources.
But the first wave will get through.
This is why greylisting to everywhere but spamtraps is a good idea. Let the spamtrap spam in, feed it directly to spamassassin, and even if the greylists get past, by then spamassassin's catching it.
Alternately, there's razor and pyzor, but I honestly don't know much about that.
Dude, spamassassin didn't recognize that message as spam.
DNS_FROM_OPENWHOIS, HELO_DYNAMIC_DHCP, RCVD_IN_BL_SPAMCOP_NET, RCVD_IN_PBL,RCVD_IN_XBL, and RDNS_NONE are origin checks, not message checks. (Well, the helo isn't technically, but forging it would be worse than correctly stating the dynamic IP.)
According to the message checks, that message scored BAYES_50=0.001 and HTML_MESSAGE=0.001 using standard spamassassin checks, and SARE_MONEYTERMS=0.681 from the very nice SAREs checks that smart mail admin install. That is almost certainly not enough to mark it as spam. And the 'money terms' probably triggered by sheer chance, considering this thing is scraping CNN.com for headlines. Other messages sent by this thing probably wouldn't trip over that.
The reason it was blocked was that it came from an IP that was current blacklisted for spamming and was clearly a dynamic IP, not that spamassassin recognized the message. Any mail from that IP would have been blocked. Spamassassin actually fell down pretty badly on the content analysis.
Any company that considers its proprietary information to be private should have a hard time arguing with that. And it's easy enough to demonstrate to management bozos how trivial it is to sniff passwords off the wire.
Ah, but this isn't a single company. We're webhosts for a dozen or so businesses, and a few cheap local non-profits, in addition to running our own websites and storefronts.
Company computers are set up with encryption. (At least since I discovered that no one else was using it.) It's the other guys who aren't.
But your idea isn't a bad one. I need to figure out if I can determine from the logs who's using TLS over standard ports (I know I can see who's using SSL ports.) and start talking about a 'security upgrade' that will, sadly, require certain people to fix their email clients.
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.
Godaddy doesn't have to hand out the certs they use. They simply have to set up a listening server on port 443 with the same virtual domain setup they have, and put a * cert on that.
However, making it indistinguishable from plaintext is a bad idea.
I wish you would EXPLAIN WHY instead of just saying it is. Just asserting things does not make them true.
An encrypted connection without authentication should be trusted, by the end user, as much as plaintext. I'll accept that. (1)
So how is making indistinguishable from plaintext a bad thing?
1) Although I will still argue that the system as a whole is much more secure from outside tampering, in the same way that sealed envelopes are more secure than postcards, despite the fact that almost anyone can file a change of address form at a post office or steal from their mailbox and intercept someone's mail, open the envelopes, and replace them in the end mailbox after tampering. 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.
This is the sort of thing we could have with opportunistic encryption using IPsec.
The problem with IPsec is, frankly, it is never going to actually happen.
And the problem with SSL is that there's no protocol-level independent generic 'negotiation'. It really really should have been designed to start plaintext and switch over, which would have allowed magically building it into every TCP server. TLS is designed to switch over, but not in a protocol independent way, so that's even more annoying.
I recognize that that's the status quo, but it's easy enough to fix. Admins just need to disable the cleartext ports and publish instructions for their users (not necessarily in that order ;^). Every one of my mail users uses IMAPS, because port 993 is the only protocol available. And even if they were to muck up the client config by changing the port to 993 without checking the SSL/TLS box, they wouldn't be able to get to the point of sending IMAP credentials in the clear, because the IMAP client won't be able to read a server hello.
Ha, I wish I had as much authority over my server as you. There's no way I could justify breaking everyone's mail connection...again.
I have actually done something like this once, I stop accepting mail submissions on port 25 and made everyone use the smtp submission port. (And the stupid smtps submission port) I was able to justify that because about every month someone would call and tell me 'the mail server was broken', when in fact they were on a new connection, or their ISP had just started, to block port 25. And I eventually said to hell with it and made everyone switch off 25 at once, as I was able to convince my company that, eventually, the amount of problems using port 25 was causing outweighed the amount of problems switching it off all at once would cause.
I doubt I can use the same logic for unencrypted connections. If it's not broken don't fix it is the motto at most companies, and definitely don't fix it in a way that breaks current setup for people.
Meanwhile, I run SSL ports, if anyone uses them, and I have TLS switching on my main ports. Which means if anyone's bothered to click any security setting, or the client does TLS by default, it's encrypted.
Grepping the logs, almost no one does.
Except that it is less secure than an unencrypted site. The reality is, if a user goes to a fraudulent copy of their bank's site, and it has an SSL certificate which is self signed, it SHOULD tell the user that the site may not be passing itself off as what it claims to be.
I don't know in what universe self-signed sites are less secure than unencrypted ones, or even how that's supposed to work. I can't even imagine how you can be less secure than unencrypted.
How many domains do you need to support, exactly?
About a dozen on the server I've got could reasonable benefit from an encrypted, in that they have moderately sensitive information passing over them. Any CMS, for example, has at least an admin interface.
First, Joomla? Really?
And your ideal CMS is...?
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.
You are arguing in circles. The reason it cost that much is that Godaddy gives you your own IP and cert.
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. (Heck, it wouldn't cost them anything.)
In fact, thanks for that example, I think it just demonstrated my point for me better than I ever could.
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.
And neither do I. Moreover, I'm failing to see why you think that failing to see why a MitM attack would be implemented somehow demonstrates your point.
Normal human beings are not subject to MitM attacks that SSL would protect them against. They really aren't.
Moreover, if they are, either they're going to fall for it regardless, or they're not going to fall for an unauthenticated connection that look sufficiently different from an authenticated one.
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 only need to be faster than the DNS server for one response -- or, for that matter, the DHCP server. After that response, the client will connect directly to me.
If you are talking about targeted attacks, my point about encryption makes more sense. Because people use the same passwords all over the place. A single cleartext login and you've won.
Moreover, as I've repeatedly pointed out, if you're going to MitM someone with a targeted attack and editing web pages, the logical thing to do is to simply set up a real SSL server with a similar name to the bank, and replace the links in the banks cleartext webpages to that place.
Or just don't use any SSL at all.
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.
I'm not sure why having the option to have unauthenticated encrypted connections helps any of those in the slightest.
I'm arguing that in a context where one might be expecting security, we shouldn't pretend something is more secure than it is. And I'm arguing that when there's a finite amount of development time to be spent improving browsers, I'd much rather it be spent on things like the HTML5 video tag, SVG, standards compliance, Javascript performance, etc, rather than on making mediocre security easier.
That's it. That's where you're at. You have no objection except the time it would take?
Well, okay then. I'm done.
I mean that every protocol has to define a unique way to start TLS negotiation: LDAP sends a particular OID, SMTP uses STARTTLS, IMPP uses a tag, etc. Then the protocol has handle various failures gracefully.
Yeah, I agree. That's why I wish the telnet negotiation protocol itself had included SSL, enabling essentially all line-mode TCP/IP connections to switch to SSL on the fly.
Then we could have avoided all this silliness. All connections start plaintext, all of them switch to SSL without sending a single byte in-band. (Except if it needs to, like HTTP.)
That way it could be, like you say, a layer on top of the application. You'd probably get it free with sockets in libc. Stick a flag on the socket when you make it, and it only accepts SSL.
(Even better, of course, would have been, instead of inventing SSL, invent something that works like SSL entirely at the telnet negotiation level, where all connections are just 'plaintext SSL' connections, and to go encrypted, you just change the encryption used. But I don't know the history well enough to know if that would have been possible.)
Furthermore, SSL's being a mixed binary and ASN.1 protocol makes it very squirrelly when a line-based protocol such as IMAP or SMTP switches it on. At best, it's, shall we say, aesthetically displeasing.
No kidding. That's probably the worse method possible.
I know what you're saying about multiple ports being better than single 'upgradable' ports, and in a way they are, but having two ports means every piece of software in existence defaults to the unencrypted one.
So while you talk about hypothetical misconfigured software that someone failed to check 'Don't connect if cannot secure the connection', what's actually going on is that almost none of the population is using SSL ports at all. Their mail client defaulted to the standard ports, and it worked. If that port offers encryption, the mail client will upgrade, but it's not going to randomly look for the encrypted port.
I know this for a fact. I've been running a mail server for years, and it's moved between machines. Once, when I moved the mail server but not the webmail that was using the same domain name, I had to forward the IMAP and POP3 port to the new server, and I had already pointed my client there to test, so failed to notice I forgot to forward the SSL ports...for two weeks. No one even noticed. Out of forty or so people, not a single one was using an encrypted connection, not a single one complained their email stopped working. I only caught it when I fixed my client to use the old server name and couldn't connect.
SSL ports are only 'more secure' if there's a set of people who would go around setting up their client to use that port, but not setting up their client to require encrypted connections. I suspect this set of people does not, in fact, exist, and even if it does, it is vastly outnumbered by the people who just accept the defaults if everything works.
Within a year or so, hopefully, virtually hosted SSL sites will be commonplace.
Not until IE7 on XP supports it. For some reason, IE7 does on Vista, but not XP. Despite what MS likes to pretend, XP will be around a long time.
This wouldn't be possible in the switching system you advocate for.
Sure it would. The telnet protocol allows both ends to specify requirements, and results in a disconnect if the other end doesn't support it. (In fact, it appears to already support SSL, but I suspect that doesn't include certs.)
Granted, the client could lie, but that would be a protocol violation, and if we're considering those, nothing stops a client from spewing plaintext into a SSL connection either.
That said, the problem there is poorly designed protocols that allow one greeting unparsed message from the server and then the client instantly sends the login. This was yet another protocol stupidity, right up there without allowing switching to SSL via telnet negotiation. (Although if we'd used the latter, we wouldn't have worry about the former...telnet negotiation happens before any communications at all.)
SMTP, interestingly, doesn't have this problem, because SMTP wasn't designed with authentication in the first place. The server has to state the ability to login, via ESMTP options. IMAP, being a late designed protocol, doesn't have this problem either.
With both IMAP and SMTP, you connect, and get a message from the server, but that message has to state the various methods you are allowed to login.(Along with various other options.) The server can, in fact, state no login methods at all, and just present the 'I can switch to SSL' option. After the switch, it can present the login methods again.
Furthermore, a switching system entangles application protocols with the constantly mutating TLS, which would make maintenance of both more difficult.
I don't know what you mean by that. SSL negotiates itself quite well between different versions. A lot of SMTP traffic already magically switches itself to SSL. I myself have let my mail server switch to SSL (Well, TLS) on demand, and have had over 500 TLS connections the last two days. (Which is actually absurdly high for the amount of mail we get, so either spammers are using SSL or my grep failed.)
Although obviously, looking at it from that direction is stupid. Our mail server (postfix) also attempts to negotiate SSL connections for outgoing mail, and I've never seen mail bounce because it couldn't negotiate a connection.
Certificates change regularly for legitimate reasons. I see no reason to confuse users by alerting them when this happens.
Let me restate: Users should be alerted when an self-signed cert changes to another self-signed cert, or when a CA-signed cert changes to a self-signed cert.
Yes, what specific problem are you talking about? HTTP is for anything that doesn't require a secret (mod Digest auth); HTTPS is for everything else. What's the problem?
The problem is that negotiation happens before any other communications, so that clients cannot state what website they are actually connecting to, so the server cannot present the correct certificate for that web site. Which is why HTTPS sites need their own IP.
This actually would be a problem in other protocols, except no email client expect signed-by-the-email-domain in email SSL connections.
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.
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.
IP addresses are not free.
And I've already pointed out we're not talking about businesses. Online businesses obviously need authentication. A guy who can barely afford godaddy to run his joomla discussion board does not.
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.
Yes, and I use Javascript.
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'. Public key encryption in Javascript is incredibly annoying.
HTTP auth would be an option, and this is actually what it's designed for, if it wasn't the ignored step-child of web browsers. It's a frickin giant dialog box, entirely breaking the paradigm of the web. Why they can't give a login bar along the top of the page and print the 'error' page under it, I don't know.
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.
How the heck is that 'heavy handed'? I have no problem with it.
If you're really that worried about 'https' in the URL bar, I'd be happy with a newly-defined 'httpe' or something, for encrypted but non-authenticated connections. Or a yellow warning bar that the page's origin cannot be verified.
Anything but the big pop-up implication that there's some huge security issue when someone goes from plaintext to unsigned SSL, requiring four or five clicks to get past.
Incidentally, I suspect that's some of what's causing the actual security issue of people trusting random web sites, in that people think plaintext browsing is somehow secure and people can't lie about their origin. 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.
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.
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.
There's a reason that Comcast wasn't altering torrent connections to disconnect them, and was instead sending TCP reset packages...it couldn't operate fast enough to actually edit the connections in situ. They're actually statistically sampling the connections because they can't handle the volume, and their system was operating from a copy of actual traffic, not 'in line'.
Remember, you'd have to intercept all communications. You couldn't encrypt half with one key and let the rest pass buy.
You're arguing just because something isn't technically impossible for an attacker to break means we shouldn't allow it. That's just crazy talk. We allow all sorts of 'moderate security' in the computer industry, a lot of actually aimed at passive spying, like logins for mail and http auth, which anyone could MiTM, and storefront software that doesn't store entire CC numbers, despite anyone being able to alter it to do that very quickly.
Saying 'Ha ha, anyone can MiTM, and asking for a security ability that can be defeated by it is stupid' is just security elitism. We're asking for 'wearing a badge' security, not 'fingerprint and r
I disagree. With STARTTLS, it's much easier for a misconfigured client to send credentials in the clear. Server policy may prevent those credentials from being honored before TLS establishment, but by then they've already been exposed.
Yes, it's easy for a misconfigured client to do almost anything. I mean, type the wrong domain name in, and who knows where it will send your credentials!
However, if the system had been set up to switch automatically from the start, correctly configured servers and any clients that supported SSL could switch automatically. Without any prompting or 'configuration'. If the client and server support SSL, they'd negotiate it in the connection. If one of them didn't...well, you're insecure no matter how you're configured.
Whereas, with a two port system, all clients are going to default to the unencrypted port, which means they will have no security at all. Which in actual fact is a good 95% of POP3 and IMAP users out there. They selected POP3 or IMAP, and got port 110 or 143, and that's it. (1)
And, of course, nothing would stop clients from offering a 'refuse to send credentials until encrypted' toggle. Although a more logical default, especially for mail clients, would just be to store a cert, for each connection, when they get it, and warn if it changes.
I'm not sure what problems you think having TLS-wrapped port designations causes.
Well, um, there's exactly what we're talking about, with HTTPS connections.
1) Of course, a lot of server scramble the login, but reading other people here talking about unauthenticated HTTPS, we are apparently required to assume there are dozens of MitM attempting to hijack our connections, and any 'security' that doesn't protect against that is no security at all and not worth doing. So obviously scrambled passwords are a scam...MitM can just hijack your IMAP connection, or whatever, and keep it open forever.
Well, the whole thing is set up stupidly in the first place.
The entire concept of secured-from-the-start SSL on another port was incredibly stupid. It happened with POP3, IMAP, HTTP, etc, and has caused nothing but problems.
Writing all protocols where you first connect in plaintext, and then switch to an encrypted connection, would have been infinitely more sensible.
Especially since, if we'd done it then, we could have had a OOB character defined to do that and everyone could have done it the same way. I.e, it should have been part of the 'telnet' protocol.(Yes, yes, that's not actually the 'telnet' protocol, but you know what I mean.)
Everyone's switching over now, with things like STARTTLS and the new virtual hosts for HTTPS (I believe that starts unencrypted and sends the hostname, and then flips to encrypted, but I could be wrong.), but there are always going to be clients out there that can either speak plaintext or SSL, not start plaintext and switch, so the SSL ports will be around for a long time.
Hell, I still have to run a damn encrypted 'smtps' port on 465 on my mail server, for Outlook Express, because it can't connect to the standard submission port and send STARTTLS.
Well, luckily, none of them can get mortgages right now.
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.
Not without Javascript or HTTP auth.
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?
Aaaaaand....cue the personal attacks and insinuations.
As it so happens, I do have a job, and part of that job is to run an web server with some SSL storefronts. It also runs a lot of Joomla community sites that have a slight amount of security would be nice.
Most clients support SSL for a virtual host [wikipedia.org] by now.
'Most clients', of course, not including IE6 or IE7 on XP. Which by themselves occupy >50% of the web browsing traffic. (And while half the remainer might be using more advanced browsers, the other half is using less.)
Because in the case where it is a bank site, you do want a giant fucking warning if someone's trying to MITM you.
If someone is trying to MitM your bank, you know what he'll do? He just won't use SSL.
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?
What the hell are you talking about? I said to not provide the clues for self-signed certs. People who know about the clues thus won't be fooled. People who don't know about the clues are already fooled by simply not using SSL.
I swear, people like you are so goddamn annoying. Everyone pushing for not having big warnings about self-signed certs is fine if browsers don't put up lock icons and green bars and everything, and we've been saying this from the start. It's fine if there's no indication at all it's an encrypted connection.
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. So you imagine a world where web browsers treat CA-signed and self-signed certs exactly the same, despite that being obviously fucking stupid and not what anyone is suggesting. Web browsers can indicate it however they want, or not at all, as long as they don't run around implying it's somehow less secure, and requires more work, than plaintext browsing.
We are simply suggesting that we be allowed to encrypt web pages, with no authentication, if we so choose, without bigass warnings popping up scaring everyone, so people can't trivially snoop on a connection and get passwords. (Which, despite what people seem to think, actually is a hell of a lot easier than MitMing a connection.) That is all.
No, I mean, trusting the proxy would present all SSL sites as authenticated...even ones that weren't, or were clearly the wrong name, or expired, or even revoked.
Mod parent up. This is exactly what everyone's been saying.
Although I won't mind a little yellow bar at the top of the page that notifies you that the cert has been saved and lets you mark it as trusted or remove it or whatever.
The problem is you've invented a world where all sites need verification. They clearly do not.
Slashdot, for example. You log in here, they have no SSL. Your password is transmitted in cleartext.
I would like my password to be encrypted so it's harder to see via traffic sniffing.
Yeah, and if FF popped up a message explaining that the website had presented a way to contact the same site securely in the future, although this did not confirm who they were, and ask 'if you want to store this code for the future, or just for this session, or not visit at all', that would be one thing.
Messages implying that it's somehow less secure than normal unencrypted web pages are another thing. Warning users, in big error pages and with sinister sounding warnings, when you are at least as secure as the dozens of unencrypted pages they visit every day, is just absurd.