Printable View
If you are limited to specific clients and can help them "accept" your home made certificate that's great. But if a client desires a "trusted" certificate you can get them for alot less than 1k. But on encryption, why encrypt data that is meant for public consumption? Like the latest previews of Destroy All Humans ? Its like the Chewbacca defence... "That does not make sense."
Well, in regards to the question, do you encrypt all your emails? No, unfortunately, I dont. Although I would like to (including those 'just saying hi' emails). I ask everyone who emails me to please use encryption, but I usualy get a reply email of 'how do I do that? And I will usually send them details on how to install and use either gpg or pgp. But relatively few people have actually gone to the trouble.
Why encrypt all those 'just saying hi' emails? Well, its not so much protecting the content as it is principle. It's nobody elses business what my emails contain! On a network, for example....Dsniff can give an individual a copy of every email you send over the wire. Information about where you go on the internet, every unencrypted password you send over the wire, and can even do ssh and ssl mitm. It is virtually impossible to trace this kind of attack, short of using either the snort arpspoof detection engine. arpreply or arpwatch.
Not only is it nobody elses business, but I also dont want my password sent out in plain text. That password is the ONLY thing that is keeping anybody in the world from downloading my emails!
In addition, on a private network or not. Have you ever thought about a bored admin at your ISP? They could easily employ the same technique if they so wished, to read emails, etc. It's just the principle. Like I said, I feel it's nobody elses business.
In regards to using SSL, I wouldn't mind a bit having to wait that extra second, or whatever it takes, to connect to the SSL encrypted page.
As far as the comments about not everyone having the ability to decrypt and about the cost of certificates. I dont necessarily mean having to use EXACTLY the procedures in place today, what I mean is, if everyone was in agreement about this, Operating Systems would ship with default, built in encryption.
When you sent an email, it would automatically be encrypted with the recipients key. No extra steps would need to be taken (aside from recieiving the recipients key), it would just BE.
The SSL certs would not necessarily need to be a part of every SSL page. Sites that did not need verification in the way a bank site, for example, would need, would simply be encrypted. As a standard, the procedure would undoubtedly change. SSL would just be default. A certificate would only need to be obtained for sites that needed it.
So, I'm not talking about necessarily having to use the procedures that are in place today, but a slow progression towards making these types of encrypted interactions default behavior.
The one argument I heard that I thought was definately valid was Strieks', about the overhead involved in such an undertaking for a server recieving vast amounts of traffic. That is definately a good point.
Regarding the NIDS thing...I'm not sure about the solution there. I would never want to have to give that up. A comprehensive NIDS is part of every system I install or configure. There probably would be a simple way to build in decoding with the NIDS, but that would probably slow it down considerably, which wouldn't be wanted.
But like I said, I'm just talking progression, and OS's, etc working on making these things standard. Not having to do this all with the procedures which are in place today. Those procedures would undoubtedly change some in order to make the progression of encryption as standard.
The majority of the world is using FTP, HTTP and plain text emails as it's basic protocols. All these transfers and passwords are sent in plain text. This is just way too easy! Where is the security there?
I can hear some of you saying (and one of you actually did) Why encrypt something like a web page that is intended for public consumption anyways?
Well, looking at it from that perspective, of course! Why would you?
But think of it as if this behavior had always been there. Everything in the computer world used encryption by default and always had. You probably wouldn't ask yourself that question. And also, you wouldn't have the vast amounts of vulnerabilities that exist today.
So, It's not so much that I am saying we must encrypt public web pages that everyone is going to read anyways. It's more of an overall picture I have here.
We all know very well that computing is extremely insecure. We cant count the vulnerabilities and holes and actual break-in's in the online world.
If encryption was a natural, default behavior in every transaction that took place between two hosts, some aspects of computing would be much more secure. And knowing that systems ARE so vulnerable, I'm surprised that encryption is NOT part of every transaction.
Encrypting a public web page may not make sense in and of itself. But if things were the way I am talking about, it would just happen to be encrypted like every other transaction. It wouldn't be encrypted specifically for the reason of encrypting that particular page. You understand what I am saying?
Computer security needs to come along ways before you are actually 'secure' online. And this was just something that I thought would be real easy to do, since all the technology is there now anyways. And would increase our security somewhat and in some areas. Of course, this is just one aspect of many different aspects that need to be looked at if we are ever going to be even somewhat secure onlineg.
And beyond what's already been said...think about protocols like ARP. There are absolutely NO security features bult in whatsoever. Arpspofing is trivial. How secure is that? And today, we still use FTP and other protocols/tools (Hopefully nobody still uses the rtools for christ sake!) that send your password over the wire in the clear! My god, we all know how trivial it is to sniff network traffic, who in their right mind would build a tool/protocol that sends your private password over the network in the clear? Thats just crazy. And so that's what I am saying. We already have the kow how to build more secure tools that do not do this sort of thing. Look how good the OpenSSH package is. Not only are the tools extremely secure, but not ONE of the tools does anything as stupid as sending out a password in plain text! And that is the point. Why in the hell are we still using these tools? (we, as in a whole)
We can all sit down on a network and watch/log (if we so choose) every packet that comes in or goes out. Now, if your password is being sent over that wire in the clear, you no longer have any security in that account. And if you used the same password on the rest of your system (which many do), you no longer have any security whatsoever on your entire system.
That is really the point I am trying to make. Not one of us can count all the vulnerabilities that are around today. And with such a high insecurity rate..there is no way in the world that anyone should be employing tools/protocols that do things like sending passwords over the wire in plain, clear text. And since we already have the ability to employ more secure methods, especially in the sense of NOT sending out plain text passwords, it just doesnt make any sense why plain text tools are still in use, AND the standard to boot!
We (as a wole) REALLY need to start moving towards the secure tools as a standard and abandon tools/protocols like FTP for one example, that employ plain text password transactions. That just seems obvious to me.
If everything is encrypted, then nothing is safer than anything else... My personal site is as secure as your banks...
If everything was encrypted, it would probably be a universal type of encryption, which would be broken within months if not less, hence making the encryption useless.
Interesting point, Grunt.
What about the plain text password transactions, though? Do you think that it should stay that way?
Total encryption is, in its self insecure. Use all possible substitutes for plain text and you increase the possiblity of cracking the encryption. Encryption should only ever be used for confidentual information. It matters not, what encryption is used, the implimentation and usage is all important.
But hay what do I know.
ALL passwords should be encrypted, and the password itself should be complicated so that it cannot be easily cracked.Quote:
Originally posted here by Dr. Psy
Interesting point, Grunt.
What about the plain text password transactions, though? Do you think that it should stay that way?
You MUST encrypt all things that NEED to be encrypted, special things, passwords, confidential information, etc. But the instant you encrypt all the crap that doesn't need it, your passwords and confidentials lose protection.
This is an interesting argument we have here...
I side on the "only information worth encrypting should be encrypted" camp.
Let's first make something clear: universal encryption is not technologically possible yet.
There's a couple major issues here:
1- There's just no encryption mechanism that's universally employable: you can't encrypt e-mails with ssh, you can't vpn or browse with pgp, you can't IPSec your e-mail stored on your harddrive...
2- In the same way as issue 1, there are many diffrent levels and ways in which data can be encrypted: should this "universal" encryption be done at the network, transport, session, application, storage, etc level? Sure there are existing cipher mechanisms for all of these, but they all use diffrent confidentiallity (ie: encryption) and more importently *authentication* methods, which all require either diffrent costly architectures or user involved manual intervention.
3- Encryption without authentication is WORTHLESS. LEt me quote you and reply:
Certificate have one and only one purpose: to prove that the person who sent a message is actullay who they claim to be. CA charge you for identity verification. SSL is not infalible: MITM attacks are just as possible against https than against plain http, that is if the user does not take care to validate the certificate/key fingerprint. If their are no certificates/fingerprint verification at all, MITM attacks are undetectable.Quote:
"The SSL certs would not necessarily need to be a part of every SSL page. Sites that did not need verification in the way a bank site, for example, would need, would simply be encrypted. As a standard, the procedure would undoubtedly change. SSL would just be default. A certificate would only need to be obtained for sites that needed it."
And this is actually what's going on right now with MS Remote Desktop/terminal services: MS has hardcoded the signing key in the DLL. (http://www.ocipep.gc.ca/opsprods/adv...AV05-023_e.asp)
SSH for example will warn you when the remote hosts's key fingerprint has changed, warning you of a personnal MITM. But who's to say that the original fingerprint was authentic? That requires manual OOB intervention by the two interlocutors. In the case of SSL, that's done by the CA... who charge for the service.
In the case of IPSec / IKE, that's done with the help of either shared secrets/passphrases or certs... which both require initial manual OOB intervention to setup.
In the case of PGP, this is done by validating key fingerprints by manual OOB communication and then possibly with the web of trust by signing other trusted people's keys. Still require intervention.
4- Encryption requires more code, more code means more chances of bugs and vulnerabilities.
Yeah, OpenSSH is nice. The protocol is cryptographically secure? Perhaps. The tools are extremly secure? Not so much. Remember that OpenSSH has been vulnerable toat least one known buffer overflow in the past. This is in fact the single vulnerability that cost OpenBSD it's "no default remote holes in X years".Quote:
Look how good the OpenSSH package is. Not only are the tools extremely secure, but not ONE of the tools does anything as stupid as sending out a password in plain text!
http://www.osvdb.org/searchdb.php?ac...&Search=Search
same goes for openssl:
http://www.osvdb.org/searchdb.php?ac...&Search=Search
5- While OpenSSH secures your password, it also prevents an NIDS from seing the multiple authentication failiures of a brute force aginst it. Same goes for webserver vulnerabilities while using ssl. In the case of a https server, workaround architectures exist like using a reverse https proxy with a cleartext segment going to the actual http server, over which the NIDS can sniff. But that's just one more argument for the unecessity of encrption everywhere.
6- Of course couldn't avoid mentionning the computing overhead and additionnal transaction latency imposed by encryption.
7- Encrypted stored data is worthless if you loose the key, or passphrase, or employee who was the only one to know the passphrase to the key which he had on a floppy on him when his plane crashed in the middle of the atlantic. This means you NEED recovery procedures, which are an additionnal burden when in fact you just wanted to recover your family vacation pictures.
Lol! just like that: http://www.antionline.com/showthread...hreadid=268862
Now don't get me/us wrong. Encryption is paramount. But only when it's worth it and implemented securly (ie: authentication), otherwise it's just a burden.
Passwords should be encrypted yes. But only if they serve to protect private (and by private I mean anything not publicly availible) information/systems... For example, there's no sense in encrypting an anonymous FTP user's password..!
Ammo
I'm with him, do you know how many CPU cycles are going to be going just for encrypting each and every transmission? Does someone really need encryption while they download ISOs for a new version of Linux? (OK, in Govt use, yes, because then they know what you run) but come on now.Quote:
Originally posted here by ammo
This is an interesting argument we have here...
I side on the "only information worth encrypting should be encrypted" camp.
If it's a password, user name, credit card and something along those lines, yes. But come on, no one needs 4096 bit looking at Goatse... Well, I'd want that encrypted.. But you're wasting CPU.
This is really quite interesting. For those of you that thought plain text password transmission was a good idea, I'm shocked!
ammo,
"5- While OpenSSH secures your password, it also prevents an NIDS from seing the multiple authentication failiures of a brute force aginst it."
Perhaps, I misunderstand you, but my NIDS (Snort) DOES detect bruteforce password attempts. In fact, it's a major issue I am dealing with right now. Despite the fact that my SSH server uses public key authentication, it is subjected to almost daily brute force password attacks. Which my snort sensor does detect. However, that's another issue really.
Also, your point about the OpenSSH vulnerability is valid. However, compared to most of whats out there. OpenSSH has a pretty damn good record in my book. I would suggest to any company concerened about security, switching to the tools in the OpenSSH package, and drop protocols such as FTP. OpenSSH is definately the clear choice when it comes to security. Not to say that it is 100% secure, as nothing is. But I think OpenSSH will prove itself time and time again to be far more secure than the average protocols/tools.
In response to the point that if everything was encrypted, the more important data would lose security, I think is quite valid. (although, I would like to see anybody crack a 512bit Blowfish cbc ciphered transaction!) This point does carry weight.
So, I have definately stopped and rethought the position. If everything was encrypted as standard, effectively reducing the security of the more important things that need encrypting, such as financial transactions, then encryption as a standard would not be a good idea.
On the other hand, there are two forms on my site http://www.rootshellsecurity.com, one for mail and one for paper submissions (the upload script is only there temporarily, it will be replaced shortly with a text box), and both use SSL. One may argue that this is pointless, as submissions will be posted for public consumption anyways. On the other hand, I want my users to know that they are indeed submitting to Rootshell Security, and that what they are submitting is what will actually be recieved. Is this absolutely necessary? Using SSL on these form pages? Probably not. However, I like the added security that using SSL provides.
As far as plain text passwords, I am REALLY surprised that anyone would think this was a good idea. This is akin to zero security!
But I do think that the argument of lesser security for more important things in response to encryption as a standard has definately changed my opinion there.
Tools/protocols. however that send passwords in plain text will never hold up in my book The minute someone can see my password in clear text going down the wire, is when I say that this is absolutely stupid! I still think that NO tool should do this.
Thanks all for showing me a different perspective. I hear so many invalid arguments at times, it's nice for a change that someone can take my point, and actually show me a different perspective that actually carries weight! A valid point can definately sway my opinion.
How would you guys go about redesigning protocols such as ARP for security?