With secure DNS, key distribution for e.g. IPSEC or TLS becomes easier.
Whereas with existing schemes like HTTPS, the client simply caches the acquired symmetric keys as needed. And non-browser applications could poll the default browser on a system in order to use its CA-based verification; that would allow such apps to distribute their own keys safely. (That is, if you're programming in a framework that doesn't already have PKI functionality.)
I don't believe that whatever ease is gained in key distribution outweighs the technical problems and risk of abuse that DNSSEC carries. It all seems very specious to me, replacing an established address verification system with a less functional one.
Almost all of the extra overhead for crypto and/or signing is in processing the initial public key. So DNSSEC seems to make our systems work about as hard, without the benefit of encrypted data.
OTOH, having an Internet trend set in with most servers switching to SSL (i.e. HTTPS, etc) keeps the government (and corps providing its "security" snooping services) from profiling people based on their everyday choices of art, books, and ways of socializing. It takes ISPs out of the loop as far as acting as surrogate cops snooping on peoples' data.
If I wanted to further a police surveillance state, I would try to set a trend with DNSSEC instead of a different public key scheme that provides encryption along with verification for the same price... especially if the tools to implement the latter were already on everyone's system waiting to be fully used.
True. But there are quite a few more sites that use Java Webstart to run apps (not applets), which is basically unsupported and unusable on Linux x64 in any browser.
Java is not complete on Linux x64: The JNLP support needed for things like Java Webstart is either missing (Sun) or supplied by "netx" which uses a very old version of the spec. I have already experienced one game and one app that could otherwise run on a 32 bit system (but not my 64 bit systems) because of this problem, and it has me rather worried.
I would say almost any drive from 300GB & up should be free of the whining problem (which I hate). I have encountered only one drive above 120GB with the problem: a 200GB Western Digital which unfortunately I own now.
That only works for software that is being written for a highly technical audience. (I'll state that Mozilla is an exception, but they grew out of the Netscape culture.)
Indeed, every Linux-based distro comes packed with these great services and tools, but the only real promise of getting them vertically integrated and putting them to work in a modern user environment has been in association with some kind of for-profit model.
Without that, you can forget about FOSS developers focusing on delivering coherent solutions for those "stupid idiots" (end users).
Consistency is why RIM and Windows Mobile dominate in the business market. With those platforms, you know that access to certain types of data and synchronizing that customers care about (email, calendars, etc.) absolutely WILL be available.
Having a phone with a Linux kernel and misc. GUI on it guarantees, erm, uh....
Even on phones, Linux looks like a platform only to software engineers (even most app developers won't recognize it as a platform).
Maybe Google can make good with Linux-based Android, but if they do how much do you want to bet 1/2 the Slahdotters will be telling average users they should get it because it runs "Linux".
The early crypto-nerd set failed in one very important respect:
They didn't make basic information about public key encryption and signing widely available in an approachable manner. Also, the OS vendors like Apple and MS (and Redhat etc.) didn't represent keys as a unique class of objects, easily recognizable with built-in functions for key management. So the concept and behavior of a "key" remained slippery to people trying out schemes like PGP.
Probably the easiest way to start using public keys today is SMIME. It's built into most clients (yes, even Outlook Express). You just have to think of the 'certificate' as an ID tag with a key attached.
I think having workings with almost no rights, and who will not sue no matter how negligent or abusive management becomes, has something (a lot) to do with the desire to sire H-1Bs.
Don't know why parent would be marked "Insightful".
Hello! This is Slashdot, we LIKE general purpose computers here.
IMO you are making a silly argument to cover for Windows' malware problem (the blame for which rests partly with its crappy architecture, not just its popularity).
Carrying that distinction further would be to have standard battery sizes so that one's 3 year-old phone isn't orphaned by an unavailable replacement battery (or aftermarket replacements that are low quality or outrageously expensive).
That, plus a standardized charging socket (like mini USB) for phones could make a positive economic and environmental impact.
Now, when there is a real risk with some option, people do pay atention.
So then, why introduce an outright distortion in the process by claiming any self-signed cert is "invalid"?
Users of such sites aren't untouched by this change: New users will likely encounter the new error before they see any explanation from the webmaster; Occasional visitors who used to accept only for a session will now see a page that simply won't load. The latter may not care about security, but in both cases this error is leaving the user with an initial impression that the webmaster is some kind of incompetent or scammer.
I disagree - Too much transparency, and the user won't even know what certs are. Then you have a worst-case scenario, where the user doesn't even notice the lock icon, much less understand a certificate warning dialog; people tend to be very dismissive of what they don't understand.
A web culture that includes self-signed certs and webmasters who are willing to explain to their users what a cert is will resist attacks far more effectively than the head-in-the-sand culture we have now.
Adults know what to do with keys and keyrings. Its how we manage our security without always appealing to central authority. But your position assumes that adults should be saved from themselves by insulating them from the notion of digital keys and keyrings used with the Internet. The more that assumption is advanced in place of user education, the more centralized authority schemes we have to bring online.
Thanks. That's an interesting scenario for that use case. There are probably a number of other plausible scenarios, too.
Probably the strongest argument in favor of 'C' is that an attacker would have to have always MITM'd your connection and never, ever stop or else be discovered. Its unlikely that anyone could sustain that level of sabotage, irregardless of whether the user changes ISPs, or takes their laptop to different APs in different cities or countries. Some of the site's users may also use VPN and proxies from time to time, which would also open the attack to discovery. (Still, I would publish my cert's fingerprint anyway as its so easy to do.)
So, yeah, case 'C' is quite valid assuming the people involved don't get the wrong idea about accepting certs (e.g. that accepting one from a blog being OK makes accepting one from a bank OK too).
Yes, and in the cases you have described, Firefox will not show any warnings at all. It will treat it as trusted since you've already verified the certificate.
Incorrect. If the method of installing and/or verifying a cert is initiated by accessing the website in question, then the draconian/inappropriate warning will appear.
In fact all of those cases I listed (like verifying a fingerprint from printed correspondence) are normally done with the browser - it's the simplest way. You click the lock icon, then match the fingerprint in the dialog window to what is on paper or spoken to you over the phone: Voila, validated certificate.
Slashdot Mirror
Because changing DNS to TCP globally would cause a lot of networks to grind to a halt. I believe DNSSEC allows you to keep things UDP and fast.
I don't mean DNS over TCP. I'm talking about protocols like HTTPS making attacks on regular DNS futile.
With secure DNS, key distribution for e.g. IPSEC or TLS becomes easier.
Whereas with existing schemes like HTTPS, the client simply caches the acquired symmetric keys as needed. And non-browser applications could poll the default browser on a system in order to use its CA-based verification; that would allow such apps to distribute their own keys safely. (That is, if you're programming in a framework that doesn't already have PKI functionality.)
I don't believe that whatever ease is gained in key distribution outweighs the technical problems and risk of abuse that DNSSEC carries. It all seems very specious to me, replacing an established address verification system with a less functional one.
...over ubiquitous use of SSL?
Almost all of the extra overhead for crypto and/or signing is in processing the initial public key. So DNSSEC seems to make our systems work about as hard, without the benefit of encrypted data.
OTOH, having an Internet trend set in with most servers switching to SSL (i.e. HTTPS, etc) keeps the government (and corps providing its "security" snooping services) from profiling people based on their everyday choices of art, books, and ways of socializing. It takes ISPs out of the loop as far as acting as surrogate cops snooping on peoples' data.
If I wanted to further a police surveillance state, I would try to set a trend with DNSSEC instead of a different public key scheme that provides encryption along with verification for the same price... especially if the tools to implement the latter were already on everyone's system waiting to be fully used.
Correct. OpenJDK uses the outdated Netx component.
Really.
Any webstart program that uses a JNLP format version greater than 1.0 (i.e. most of what you will find out on the web) will fail.
The Netx software used to handle webstart JNLPs is dead. The project was last updated February 2003!
The only source for a current JNLP handler is Sun, and they only supply it for Linux with their 32 bit Java package.
True. But there are quite a few more sites that use Java Webstart to run apps (not applets), which is basically unsupported and unusable on Linux x64 in any browser.
Java is not complete on Linux x64: The JNLP support needed for things like Java Webstart is either missing (Sun) or supplied by "netx" which uses a very old version of the spec. I have already experienced one game and one app that could otherwise run on a 32 bit system (but not my 64 bit systems) because of this problem, and it has me rather worried.
Can you elaborate on that?
Yeah, I wish he would just tell us how he really feels.
(Snicker.... :)
You're right and I've noticed the same thing.
I would say almost any drive from 300GB & up should be free of the whining problem (which I hate). I have encountered only one drive above 120GB with the problem: a 200GB Western Digital which unfortunately I own now.
That only works for software that is being written for a highly technical audience. (I'll state that Mozilla is an exception, but they grew out of the Netscape culture.)
Indeed, every Linux-based distro comes packed with these great services and tools, but the only real promise of getting them vertically integrated and putting them to work in a modern user environment has been in association with some kind of for-profit model.
Without that, you can forget about FOSS developers focusing on delivering coherent solutions for those "stupid idiots" (end users).
Indeed. A person can't even see an actual electronic "ballot"!
We are supposed to be satisfied with a facsimile drawn on the screen, echoed through many abstraction layers.
That is not good enough for anonymous transactions, especially ones with such high stakes.
I2PSnark is their bittorrent client, check it out.
Here is a short Howto for I2P.
They are still trying to gain a critical mass but the network essentially works.
And we're not going to shell out 1 grand for a laptop with only 2 USB ports.
Consistency is overrated.
Bzzzt! Try again...
Consistency is why RIM and Windows Mobile dominate in the business market. With those platforms, you know that access to certain types of data and synchronizing that customers care about (email, calendars, etc.) absolutely WILL be available.
Having a phone with a Linux kernel and misc. GUI on it guarantees, erm, uh....
Even on phones, Linux looks like a platform only to software engineers (even most app developers won't recognize it as a platform).
Maybe Google can make good with Linux-based Android, but if they do how much do you want to bet 1/2 the Slahdotters will be telling average users they should get it because it runs "Linux".
The early crypto-nerd set failed in one very important respect:
They didn't make basic information about public key encryption and signing widely available in an approachable manner. Also, the OS vendors like Apple and MS (and Redhat etc.) didn't represent keys as a unique class of objects, easily recognizable with built-in functions for key management. So the concept and behavior of a "key" remained slippery to people trying out schemes like PGP.
Probably the easiest way to start using public keys today is SMIME. It's built into most clients (yes, even Outlook Express). You just have to think of the 'certificate' as an ID tag with a key attached.
I think having workings with almost no rights, and who will not sue no matter how negligent or abusive management becomes, has something (a lot) to do with the desire to sire H-1Bs.
What, he can't be any worse than his brother Tony.
Don't know why parent would be marked "Insightful".
Hello! This is Slashdot, we LIKE general purpose computers here.
IMO you are making a silly argument to cover for Windows' malware problem (the blame for which rests partly with its crappy architecture, not just its popularity).
Carrying that distinction further would be to have standard battery sizes so that one's 3 year-old phone isn't orphaned by an unavailable replacement battery (or aftermarket replacements that are low quality or outrageously expensive).
That, plus a standardized charging socket (like mini USB) for phones could make a positive economic and environmental impact.
Now, when there is a real risk with some option, people do pay atention.
So then, why introduce an outright distortion in the process by claiming any self-signed cert is "invalid"?
Users of such sites aren't untouched by this change: New users will likely encounter the new error before they see any explanation from the webmaster; Occasional visitors who used to accept only for a session will now see a page that simply won't load. The latter may not care about security, but in both cases this error is leaving the user with an initial impression that the webmaster is some kind of incompetent or scammer.
I disagree - Too much transparency, and the user won't even know what certs are. Then you have a worst-case scenario, where the user doesn't even notice the lock icon, much less understand a certificate warning dialog; people tend to be very dismissive of what they don't understand.
A web culture that includes self-signed certs and webmasters who are willing to explain to their users what a cert is will resist attacks far more effectively than the head-in-the-sand culture we have now.
Adults know what to do with keys and keyrings. Its how we manage our security without always appealing to central authority. But your position assumes that adults should be saved from themselves by insulating them from the notion of digital keys and keyrings used with the Internet. The more that assumption is advanced in place of user education, the more centralized authority schemes we have to bring online.
Thanks. That's an interesting scenario for that use case. There are probably a number of other plausible scenarios, too.
Probably the strongest argument in favor of 'C' is that an attacker would have to have always MITM'd your connection and never, ever stop or else be discovered. Its unlikely that anyone could sustain that level of sabotage, irregardless of whether the user changes ISPs, or takes their laptop to different APs in different cities or countries. Some of the site's users may also use VPN and proxies from time to time, which would also open the attack to discovery. (Still, I would publish my cert's fingerprint anyway as its so easy to do.)
So, yeah, case 'C' is quite valid assuming the people involved don't get the wrong idea about accepting certs (e.g. that accepting one from a blog being OK makes accepting one from a bank OK too).
Yes, and in the cases you have described, Firefox will not show any warnings at all. It will treat it as trusted since you've already verified the certificate.
Incorrect. If the method of installing and/or verifying a cert is initiated by accessing the website in question, then the draconian/inappropriate warning will appear.
In fact all of those cases I listed (like verifying a fingerprint from printed correspondence) are normally done with the browser - it's the simplest way. You click the lock icon, then match the fingerprint in the dialog window to what is on paper or spoken to you over the phone: Voila, validated certificate.
Self signed certs can not be authenticated...
I really wish you people would stop whining...
Signed,
Someone with an actual clue about cryptography.
Oh?
You are so clueful about crypto that you don't know what fingerprints and out-of-band authentication are?
My.
Self-signed SSL certs work marvelously in a number of use cases:
A) When an admin or user adds the cert to a client machine (like a laptop) in a secure environment.
B) When fingerprints are verified out of band, such as over the phone, over alternate sites and protocols, printed correspondence, etc...
C) When its only necessary to know that you are communicating with the same party you were last time.
Granted that 'C' may be a rare and less secure case, but the first two are easy to perform and can meet a high standard for authentication.
SSL certs don't provide encryption. They provide authentication...
Try again.
The only usage of certs that matters within a web browser is HTTPS, which employs both authentication and encryption at the same time.
Your splitting of hairs is so contrived that one has to forget everything about the use cases involved for your explanation to make any sense.