> > if you are someone like bin Laden, you probably can safely > > assume the $5 wrench trick (aka harsh interrogation) can by > > sidestepped by suicide.
> Yeah. That's why he shot himself in the head! Twice!!
Of course, that's still pretty lame compared to the at least 35 times Peter Gutmann would have used...:-D
> Travelling 4000 miles to speak to someone or just see their face is, > for the most part, quaint and pointless.
And this is why nerds can't, for the life of them, design programs with actual people (users) in mind...they just don't get it what could possibly be so important about people...sigh.
> There is a reasonably straight forward technical solution, that > could be implemented in a future SSL protocol, to resolve the > issue of trust when you already have an account on a site. A host > site can add the hash of your password to the symmetric key > used after the key exchange, your browser can then do the same > on your side. > This is essentially using a a shared secret (the hash of your > password) as part of the symmetric key. The result is that no one > in the middle can intercept your communication even if they have > compromised the certificate.
Good idea and I raise you, at least for login sites, a public key solution. When registering you don't pick a password, repeat it, type a security question etc. blabla, but you simply paste your public GPG key into the provisioned field. Not only would this serve in lieu of a site-password, but also, as in your suggestion, could be used to encrypt SSL-type exchanges between server and client browser to prevent MITM's. If SSL public keys would be further signed (signable) by actual people and thus would be part of a human web-of-trust, we'd be a long way ahead in the right direction, IMHO.
> The reason that you can't run a mail server at home is not a > shortage of IP addresses in IPv4 but that most ISPs will refuse to > deliver mail from dynamic IPs since thats mostly home > subscribers (running an old an unpatched version of Windows > and are therefore most likely part of a botnet) and not larger > companies. That problem won't change with IPv6.
Actually it most likely will. With IPv6 there's no need for *dynamic* IPs. Every person can have their own and that can be tied distinctly to that person (same as you street address on letters). So I don't see Spam as an issue, even with malware, as the IP can simply be blocked, as opposed to DHCP-pool'ed IPs.
Besides, who say, mail agents can't have a feature specifically allowing only specific other people to remail through your address. Presumably this would only be people you actually know. The mail program would somehow communicate this to the mail program of the person in question, so they can establish their routes when wanting to remail.
I wonder, how the adoption of IPv6 will cause a paradigm shift here. It would allow every user to host his very own mail server right at home (though technically already doable even with v4), incl. SSL etc.. Subpoenas for your mail would need to be real search warrants, the entire (mail) hosting industry would mostly become irrelevant and people could send mail the good old-fashioned way *directly* to each other ('s IP). Snoops would have an awful time with this, when they have their established live-feeds from the various Telco's providing (your) connectivity, but all they see is encrypted SSL traffic with Un-MITM-able self-signed (and out-of-band verified) certificates going on between people. A whole mesh could be created this way, even defeating traffic-analysis. Every user a remailer....oh the possibilities....
Like it, but would simply place public key on server, private key stays local. Server send challenge encrypted with public key, you decrypt with private. Client/browser sends it back, optionally encrypted with servers public key. Voila! No need for passwords at all, except on your local private key.
Perhaps someone with more knowledge than myself can comment on this topic:
Would it be:
1. possible and 2. make a positive difference
to have some sort of shielding between phone and body? For example, shielding on the inside of pocket pants etc., that'd prevent the signals to go towards the body where we don't need them anyway? What would you need and would it work?
> What happens when, say, Eric Schmidt leaves Google?
Well, Eric Smith doesn't stop being Eric Smith and Google is still, well, Google. The signature is, for the time being, still valid since it says nothing except "This key really belongs to Google Inc. Sincerely, Eric Smith". The key would then be updated by having the new CEO sign it. A mechanism to put a time limit on signatures may also be useful (akin to having the option of having keys expire at some point).
I, for one, am grateful that this incident happened and the bad state of affairs gains publicity. Let's not forget, this has been possible for years and chances are extremely high, that it's been exploited by various Stasi's already....except nobody's really been noticing it.
As far as I am concerned, the SSL CA model was really a DOA. Except with the 1990's gold rush of "e-commerce" nobody cared for anything but the quick and dirty solution. Which is, what we're still stuck with. Hardcoding "trust" is so foreign to how the world in general and people in particular work, that it's not even funny in its ridiculousness. While I don't have ideal solutions either, I imagine, that real trust can only be established by tying domain certificates to actual people. Think GPG-style WOT. Think specifically Lawrence E. Page (CEO, Co-Founder and President, Products), Eric Schmidt (Executive Chairman) and Sergey M. Brin (Co-Founder and President, Technology) signing GPG-style Google's master key. Each company, depending on size, would then be their own CA and chances are, they have better control over what certs get created for which of their domains. Yes, signatures too can be forged as can the keys to create them with. But this is where the WOT would lend itself to. Even if they hate each other, Google master keys and Microsoft's could be cross-signed. Win-Win for both companies. And tied to real people (CEO's, CTO's etc.). Combine that with something like Perspectives (that too could be crowd-sourced!), DNSSEC, and SSH-style key-saving on first connect (also accomplished with the Certificate Patrol FF plugin), and you can completely get rid of the useless, expensive and insecure CA model.
> Only if the client has the [self] certificate ahead of time. Otherwise it > really isn't [more secure than plain http]
Actually all you need is the fingerprint of the certificate to verify, not the whole cert.
For example, as hosting provider you may provide PHPMyAdmin logins for your customers, so they can admin their databases from the browser. A self-signed certificate from the hosting provider to secure that login is perfectly reasonable, as is a phone call to the customer providing them with the fingerprint of the self-signed cert to prevent a MITM. And yes, that is most certainly more secure than plain-text HTTP. In fact, it's even more secure than the gazillion-trusted-potentially-MITM-enabling CA certs!
> Or they go camping and it turns out there's a whole week of > outletlessness ahead.
The horror....the horror...
Seriously, if I was going camping with my family and my kid even so much as mentioned (3)DS[i|lite], PS[3|P] while in the paradise of nature, I would smear him with honey and start making bear calls to focus his mind on other things in a hurry...
Slashdot Mirror
> > if you are someone like bin Laden, you probably can safely
> > assume the $5 wrench trick (aka harsh interrogation) can by
> > sidestepped by suicide.
> Yeah. That's why he shot himself in the head! Twice!!
Of course, that's still pretty lame compared to the at least 35 times Peter Gutmann would have used... :-D
> if you are someone like bin Laden, you probably can safely
> assume the $5 wrench trick (aka harsh interrogation) can by
> sidestepped by suicide.
Yeah. That's why he shot himself in the head! Twice!!
Is the router running ReiserFS?!
> What happens if you simply refuse to hand over your phone?
What happens, if you DO want to hand it over and reach into your jacket, while the nervous cop has his hand on his gun...?!
Anyone have experience with that model? Seems to look good, but never saw it 'live'...
Also seems to be very hard to get. Even the Sony store here doesn't have it. :-/
> Travelling 4000 miles to speak to someone or just see their face is,
> for the most part, quaint and pointless.
And this is why nerds can't, for the life of them, design programs with actual people (users) in mind...they just don't get it what could possibly be so important about people...sigh.
> Every SSL web site I care about requires me to login. Why not just
> make mutual password knowledge part of the SSL handshake and
> be done with it?
Or a random challenge encrypted with your GPG key. Advantage is, you could use that for every such site.
> There is a reasonably straight forward technical solution, that
> could be implemented in a future SSL protocol, to resolve the
> issue of trust when you already have an account on a site. A host
> site can add the hash of your password to the symmetric key
> used after the key exchange, your browser can then do the same
> on your side.
> This is essentially using a a shared secret (the hash of your
> password) as part of the symmetric key. The result is that no one
> in the middle can intercept your communication even if they have
> compromised the certificate.
Good idea and I raise you, at least for login sites, a public key solution. When registering you don't pick a password, repeat it, type a security question etc. blabla, but you simply paste your public GPG key into the provisioned field. Not only would this serve in lieu of a site-password, but also, as in your suggestion, could be used to encrypt SSL-type exchanges between server and client browser to prevent MITM's.
If SSL public keys would be further signed (signable) by actual people and thus would be part of a human web-of-trust, we'd be a long way ahead in the right direction, IMHO.
> The reason that you can't run a mail server at home is not a
> shortage of IP addresses in IPv4 but that most ISPs will refuse to
> deliver mail from dynamic IPs since thats mostly home
> subscribers (running an old an unpatched version of Windows
> and are therefore most likely part of a botnet) and not larger
> companies. That problem won't change with IPv6.
Actually it most likely will. With IPv6 there's no need for *dynamic* IPs. Every person can have their own and that can be tied distinctly to that person (same as you street address on letters). So I don't see Spam as an issue, even with malware, as the IP can simply be blocked, as opposed to DHCP-pool'ed IPs.
Besides, who say, mail agents can't have a feature specifically allowing only specific other people to remail through your address. Presumably this would only be people you actually know. The mail program would somehow communicate this to the mail program of the person in question, so they can establish their routes when wanting to remail.
I wonder, how the adoption of IPv6 will cause a paradigm shift here. It would allow every user to host his very own mail server right at home (though technically already doable even with v4), incl. SSL etc.. Subpoenas for your mail would need to be real search warrants, the entire (mail) hosting industry would mostly become irrelevant and people could send mail the good old-fashioned way *directly* to each other ('s IP). Snoops would have an awful time with this, when they have their established live-feeds from the various Telco's providing (your) connectivity, but all they see is encrypted SSL traffic with Un-MITM-able self-signed (and out-of-band verified) certificates going on between people. A whole mesh could be created this way, even defeating traffic-analysis. Every user a remailer....oh the possibilities....
> I recently did a similar study, using my girlfriend as my sample, to
> prove that 100% of humans have a vagina.
Hmm...where do you meet those....humans?
Like it, but would simply place public key on server, private key stays local. Server send challenge encrypted with public key, you decrypt with private. Client/browser sends it back, optionally encrypted with servers public key. Voila!
No need for passwords at all, except on your local private key.
Mon mot de passe est une table de hachage, vous mottes insensible!
Don't try this at home, kids! ;-)
Perhaps someone with more knowledge than myself can comment on this topic:
Would it be:
1. possible
and
2. make a positive difference
to have some sort of shielding between phone and body? For example, shielding on the inside of pocket pants etc., that'd prevent the signals to go towards the body where we don't need them anyway?
What would you need and would it work?
> I mean, its not like its causing strange growths to appear on my thigh
I've had that happen! Especially when the phone was on vibrate... :-/
> ...is coming in 2012!
Of course! That's when the Maeian calendar ends!
> What happens when, say, Eric Schmidt leaves Google?
Well, Eric Smith doesn't stop being Eric Smith and Google is still, well, Google. The signature is, for the time being, still valid since it says nothing except "This key really belongs to Google Inc. Sincerely, Eric Smith".
The key would then be updated by having the new CEO sign it. A mechanism to put a time limit on signatures may also be useful (akin to having the option of having keys expire at some point).
I, for one, am grateful that this incident happened and the bad state of affairs gains publicity. Let's not forget, this has been possible for years and chances are extremely high, that it's been exploited by various Stasi's already....except nobody's really been noticing it.
As far as I am concerned, the SSL CA model was really a DOA. Except with the 1990's gold rush of "e-commerce" nobody cared for anything but the quick and dirty solution. Which is, what we're still stuck with. Hardcoding "trust" is so foreign to how the world in general and people in particular work, that it's not even funny in its ridiculousness.
While I don't have ideal solutions either, I imagine, that real trust can only be established by tying domain certificates to actual people. Think GPG-style WOT. Think specifically Lawrence E. Page (CEO, Co-Founder and President, Products), Eric Schmidt (Executive Chairman) and Sergey M. Brin (Co-Founder and President, Technology) signing GPG-style Google's master key. Each company, depending on size, would then be their own CA and chances are, they have better control over what certs get created for which of their domains.
Yes, signatures too can be forged as can the keys to create them with. But this is where the WOT would lend itself to. Even if they hate each other, Google master keys and Microsoft's could be cross-signed. Win-Win for both companies. And tied to real people (CEO's, CTO's etc.). Combine that with something like Perspectives (that too could be crowd-sourced!), DNSSEC, and SSH-style key-saving on first connect (also accomplished with the Certificate Patrol FF plugin), and you can completely get rid of the useless, expensive and insecure CA model.
> Only if the client has the [self] certificate ahead of time. Otherwise it
> really isn't [more secure than plain http]
Actually all you need is the fingerprint of the certificate to verify, not the whole cert.
For example, as hosting provider you may provide PHPMyAdmin logins for your customers, so they can admin their databases from the browser. A self-signed certificate from the hosting provider to secure that login is perfectly reasonable, as is a phone call to the customer providing them with the fingerprint of the self-signed cert to prevent a MITM. And yes, that is most certainly more secure than plain-text HTTP. In fact, it's even more secure than the gazillion-trusted-potentially-MITM-enabling CA certs!
What part of FOREVER don't you understand?!
> Or they go camping and it turns out there's a whole week of
> outletlessness ahead.
The horror....the horror...
Seriously, if I was going camping with my family and my kid even so much as mentioned (3)DS[i|lite], PS[3|P] while in the paradise of nature, I would smear him with honey and start making bear calls to focus his mind on other things in a hurry...
> Up and down the middle isle of course. You can use the
> stewardesses and meal carts as hurdles.
For advanced hurdlers the seats between the isles are a better challenge...
> 1998 called? Did you warn them about 9/11?
I did. They already knew about it. :-)
> Yep, the one-line answer is:
> It's too CPU-intensive for the server.
Hey...1998 called and wants its one-line answers back!