Good idea. I agree. I switch ports for things, too. Helps to avoid worms. But...
Scanned at 2011-08-28 11:37:25 PDT for 54s PORT STATE SERVICE VERSION 3390/tcp open microsoft-rdp Microsoft Terminal Service
It's still possible to see where your RDP port is. So a dedicated attacker or a port-scanning worm (I'd be amused to see one of those) uncovers your hide.
Request-Range? I'm not familiar with that request-header field. Searching now, I can't find it in RFC 2616 either. Could you point to where you heard about it?
Yeah, kind of. Except I disclosed my relationship to OnLive.
I think it's a neat technology and I'm interested in what other people (would genuinely) think. Usually you get people saying "It'll never work" though they've never tried it. And it's trivial to try it. That bugs me. I hate people talking out their asses like that.
I also flog Perspectives every time HTTPS woes are mentioned. I have no relation to the project, but I think it's a great technology with some hope of doing something about the CAs-are-fucked-up problem. I want the Perspectives solution investigated and reviewed. Marlinspike thinks there's something to the method -- he created Convergence. There was precious little discussion about Convergence/notaries in the last HTTPS-related Slashdot article, which was really fundamentally about Convergence. That bugs me. I hate people failing to see what's relevant.
As time goes on, you will accumulate keys from other people that you may want to designate as trusted introducers. Everyone else will each choose their own trusted introducers. And everyone will gradually accumulate and distribute with their key a collection of certifying signatures from other people, with the expectation that anyone receiving it will trust at least one or two of the signatures. This will cause the emergence of a decentralized fault-tolerant web of confidence for all public keys.
If I trust A but not B... and they both make claims about the identity of C... it still works. The least trustworthy identity in my web is B, but because it's a web, I'm able instead to trust A. Thus my web is more trustworthy than the "least trustworthy member".
I would rather you do the legwork. I was trying to prompt you.
As of the publishing of Marlinspike's article Bob Parsons was majority shareholder. It's his company. He's since sold most of the company off -- he's now under 50% -- but he's still the biggest shareholder.
Bob Parsons started the company, he owned the company, he owns the biggest chunk of the company now, his ethics continue to be highly influential. The company's history of controversy shows his influence, either directly or by setting a tone for behavior: http://en.wikipedia.org/wiki/Godaddy.com#Controversies Have you heard about Bob Parson's stance on torture?
In short, the quality of GoDaddy is related to the quality of Bob Parsons.
If folks involved in Perspectives (Mr. Wendland?) are watching this discussion, could you comment on the arrival of Convergence? It's relationship with your work?
Out of 140+ comments here only two mention Convergence. Yours, and a kind of incidental mention earlier. Even I missed it because I focused only on Marlinspike's old blog article.
Can't trust the DNS registrars (he includes a GoDaddy ad hominem )
I can only assume you don't know much about GoDaddy. Not to be mean or uncharitable, but this example drives the point home. And please note that this also is not an "ad hominem" -- there's no fallacy in pointing out the poor character of a registrar when the trustworthiness of registrars is the argument at hand.
The current system consequently doesn't add any trust over a completely DNS based system.
So, DNSSEC is no improvement (in this regard)? I think maybe you're not disagreeing with Marlinspike. He says:
So unfortunately the DNSSEC trust relationships depend on sketchy organizations and governments, just like the current CA system.
But you say "The DNS based system on the other hand has one big advantage over the SSL CA hierarchy" in that, IIUC, you don't have a "mixed scope", i.e. multiple organizations who can vouch for any domain. He addresses this:
# There's a mixed scope. Some have suggested that the problem with all of this is the scoping. That the DHS shouldn't be able to sign certificates for Chinese sites or vice-versa. To me this seems like a low bar. There are plenty of people who don't trust the DHS to sign certificates for any sites, and restricting the Chinese government to Chinese sites doesn't feel like a particularly powerful win either. So I'm also skeptical that this is the essence of the problem. "
What you're calling a relative strength here is by itself not nearly enough to warrant the switch to DNSSEC.
I roughly agree with your sentiment, but I wonder just how much "get[ting] up in the way of regular people" should be allowed. That's a long spectrum with many shades from, say, carrying signs to detonating fertilizer bombs next to government buildings.
The point of protest/demonstration doesn't seem to me to be to cause pain or even inconvenience. It's to make visible your opinion. A 10,000-person march per se, if could do it without creating traffic problems or scaring people, would achieve the goal.
Causing difficulty for others isn't a civic duty. Making known broadly-held opinion is.
DNSSEC-based domain validation is an exciting possibility. But I've heard concerns over it:
For the time being, we will make just one remark about this. Many people have been touting DNSSEC PKI as a solution to the problem. While DNSSEC could be an improvement, we do not believe it is the right solution to the TLS security problem. One reason is that the DNS hierarchy is not trustworthy. Countries like the UAE and Tunisia control certificate authorities, and have a history of compromising their citizens' computer security. But these countries also control top-level DNS domains, and could control the DNSSEC entries for those ccTLDs. And the emergence of DNS manipulation by the US government also raises many concerns about whether DNSSEC will be reliable in the future.
... I just like arguing edge cases because if a given solution's edge cases are easy to solve or to minimize, it's easier to make a solid case for adopting the solution.
Fair enough. Probably a good practice. Indeed, this is part of why I've been flogging Perspectives every Slashdot article about SSL. Among other reasons, I'm trying to promote discussion so I can better understand the issue. Thanks for your input.
I think as more browsers and servers adopt SNI, Perspectives becomes more (broadly) viable.
Shared hosting providers don't offer SNI...
I can imagine in time that budget hosting would add this feature.
"UCCs" or subjectAltName certs are just a stopgap. They can help meanwhile, but they're not a long term solution. (Not implying you think so -- I'm just talking out loud.)
I treat "fails" as including "cannot work".
Reasonable, but we should take care in our communications that folks understand the subcategory of failure. Having your cert validation system report a false positive is a decidedly different kind of failure from having it say "sorry, I can't operate reliably in this scenario".
And it's important that we talk about strengths and weaknesses in relation to other solutions. Currently used solutions, especially. The scenario in which all routes to a system are compromised and have always been compromised also undermines the Certificate Authority model.
Again, I think as more browsers and servers adopt SNI the case for a notary-based cert validation system grows stronger.
Disclosure: I'm greatly annoyed with the Certificate Authority model, with how it's so vulnerable for having so many CAs trusted by browsers, with how the CAs have profit motive to discourage a more democratic model so they can continue to bilk people.
There won't be a changed cert if the MITM has been in place since day one.
Ah. Yes, for the scenario when a system has never had any trustable connections to the rest of the world a "multiple views of the resource" kind of method wouldn't work. I believe you are correct.
But I don't think that's the problem that folks are trying to solve? How do I know my certificate for PayPal is legit? Or for my bank? Wikipedia? Google? For problems in this kind, Perspectives works pretty well, I think. Maybe you think so, too, since you use it in all your Firefoxes?
It also fails if you're trying to host more than one unrelated HTTPS site on port 443...
I think I see what you're talking about now. Thanks for your forbearance. The TLS encryption engages before the HTTP layer can communicate and agree on hostname, so there isn't a way to say which host the cert is for.
Yes, for the scenario in which you are accessing a virtual host via HTTPS, and the virtual host wasn't given its own IP address, and you can't use a wildcard host spec because the virtual domains being used won't fit the pattern (or it costs too much (but with a notary system we're enabling self-issued certs)), and you are running an SNI-less browser, or the server can't use or doesn't have an X509 v3 subjectAltName certificate (maybe it costs too much (but, again, we could self-issue)) and the browser can't do X509 v3 (though this is even more widespread than SNI), Perspectives fails to help. And, granted, such scenarios are not uncommon. But I don't think Perspectives needs to solve all these situations to be useful.
If you're using a modern Firefox, Safari, Chrome, or IE (that's a lot of users) and are going to a site that's not virtual hosting via the same IP or can do X509 v3 or SNI (that's a lot of sites), you're good to go. That's a pretty big chunk of secure browsing right there.
And I wouldn't say Perspectives "fails" in those scenarios. More precisely, it cannot work for those scenarios. Meaning you do not get a false sense of security -- you just can't use it then.
In any case, it can at least be used to augment SSL security. Without it, folks are just relying on the Certificate Authorities. *cringe*
If Anonymity allows people to show their true self, and we dont like what we see, its not anonymity thats the problem.
That's insightful. But let's not fall into simplistic thinking. The problem doesn't exist -- things go badly by means of a variety of influences. And as you're suggesting, the lack of principled ethical motivation in people is probably a major player.
Slashdot Mirror
Good idea. I agree. I switch ports for things, too. Helps to avoid worms. But...
Scanned at 2011-08-28 11:37:25 PDT for 54s
PORT STATE SERVICE VERSION
3390/tcp open microsoft-rdp Microsoft Terminal Service
It's still possible to see where your RDP port is. So a dedicated attacker or a port-scanning worm (I'd be amused to see one of those) uncovers your hide.
What about adding port knocking?
Request-Range? I'm not familiar with that request-header field. Searching now, I can't find it in RFC 2616 either. Could you point to where you heard about it?
Apache brought criticism onto themselves. The bug is more than four-and-a-half years old.
This memory allocation bug is distinct from Zalewski's bandwidth multiplying bug.
Indeed, both stem from "silly" Range handling, but they are still different bugs. I.e., the bug is not 4+ years old.
Yeah, kind of. Except I disclosed my relationship to OnLive.
I think it's a neat technology and I'm interested in what other people (would genuinely) think. Usually you get people saying "It'll never work" though they've never tried it. And it's trivial to try it. That bugs me. I hate people talking out their asses like that.
I also flog Perspectives every time HTTPS woes are mentioned. I have no relation to the project, but I think it's a great technology with some hope of doing something about the CAs-are-fucked-up problem. I want the Perspectives solution investigated and reviewed. Marlinspike thinks there's something to the method -- he created Convergence. There was precious little discussion about Convergence/notaries in the last HTTPS-related Slashdot article, which was really fundamentally about Convergence. That bugs me. I hate people failing to see what's relevant.
My housemate's an OnLive employee, so I've already tried it out. I think it's pretty good, but you can decide for yourself with their free trial.
Oh, and -- sorry -- Apache security advisory.
In more detail...
Some of the suggestions from the Full Disclosure discussion and elsewhere:
I think maybe I haven't been clear.
As time goes on, you will accumulate keys from other people that you may want to designate as trusted introducers. Everyone else will each choose their own trusted introducers. And everyone will gradually accumulate and distribute with their key a collection of certifying signatures from other people, with the expectation that anyone receiving it will trust at least one or two of the signatures. This will cause the emergence of a decentralized fault-tolerant web of confidence for all public keys.
Web Of Trust, via WP, emphasis mine
If I trust A but not B ... and they both make claims about the identity of C ... it still works. The least trustworthy identity in my web is B, but because it's a web, I'm able instead to trust A. Thus my web is more trustworthy than the "least trustworthy member".
I would rather you do the legwork. I was trying to prompt you.
As of the publishing of Marlinspike's article Bob Parsons was majority shareholder. It's his company. He's since sold most of the company off -- he's now under 50% -- but he's still the biggest shareholder.
Bob Parsons started the company, he owned the company, he owns the biggest chunk of the company now, his ethics continue to be highly influential. The company's history of controversy shows his influence, either directly or by setting a tone for behavior: http://en.wikipedia.org/wiki/Godaddy.com#Controversies Have you heard about Bob Parson's stance on torture?
In short, the quality of GoDaddy is related to the quality of Bob Parsons.
If folks involved in Perspectives (Mr. Wendland?) are watching this discussion, could you comment on the arrival of Convergence? It's relationship with your work?
Out of 140+ comments here only two mention Convergence. Yours, and a kind of incidental mention earlier. Even I missed it because I focused only on Marlinspike's old blog article.
Focus, people: Convergence
Look it over and see what you think.
A web of trust is only as trustworthy as the least trustworthy member of the web.
That's more like a "chain of trust".
Oh, and...
Can't trust the DNS registrars (he includes a GoDaddy ad hominem )
I can only assume you don't know much about GoDaddy. Not to be mean or uncharitable, but this example drives the point home. And please note that this also is not an "ad hominem" -- there's no fallacy in pointing out the poor character of a registrar when the trustworthiness of registrars is the argument at hand.
The current system consequently doesn't add any trust over a completely DNS based system.
So, DNSSEC is no improvement (in this regard)? I think maybe you're not disagreeing with Marlinspike. He says:
So unfortunately the DNSSEC trust relationships depend on sketchy organizations and governments, just like the current CA system.
But you say "The DNS based system on the other hand has one big advantage over the SSL CA hierarchy" in that, IIUC, you don't have a "mixed scope", i.e. multiple organizations who can vouch for any domain. He addresses this:
# There's a mixed scope. Some have suggested that the problem with all of this is the scoping. That the DHS shouldn't be able to sign certificates for Chinese sites or vice-versa. To me this seems like a low bar. There are plenty of people who don't trust the DHS to sign certificates for any sites, and restricting the Chinese government to Chinese sites doesn't feel like a particularly powerful win either. So I'm also skeptical that this is the essence of the problem. "
What you're calling a relative strength here is by itself not nearly enough to warrant the switch to DNSSEC.
I roughly agree with your sentiment, but I wonder just how much "get[ting] up in the way of regular people" should be allowed. That's a long spectrum with many shades from, say, carrying signs to detonating fertilizer bombs next to government buildings.
The point of protest/demonstration doesn't seem to me to be to cause pain or even inconvenience. It's to make visible your opinion. A 10,000-person march per se, if could do it without creating traffic problems or scaring people, would achieve the goal.
Causing difficulty for others isn't a civic duty. Making known broadly-held opinion is.
DNSSEC-based domain validation is an exciting possibility. But I've heard concerns over it:
For the time being, we will make just one remark about this. Many people have been touting DNSSEC PKI as a solution to the problem. While DNSSEC could be an improvement, we do not believe it is the right solution to the TLS security problem. One reason is that the DNS hierarchy is not trustworthy. Countries like the UAE and Tunisia control certificate authorities, and have a history of compromising their citizens' computer security. But these countries also control top-level DNS domains, and could control the DNSSEC entries for those ccTLDs. And the emergence of DNS manipulation by the US government also raises many concerns about whether DNSSEC will be reliable in the future.
Could you address those?
... I just like arguing edge cases because if a given solution's edge cases are easy to solve or to minimize, it's easier to make a solid case for adopting the solution.
Fair enough. Probably a good practice. Indeed, this is part of why I've been flogging Perspectives every Slashdot article about SSL. Among other reasons, I'm trying to promote discussion so I can better understand the issue. Thanks for your input.
I think as more browsers and servers adopt SNI, Perspectives becomes more (broadly) viable.
Shared hosting providers don't offer SNI...
I can imagine in time that budget hosting would add this feature.
"UCCs" or subjectAltName certs are just a stopgap. They can help meanwhile, but they're not a long term solution. (Not implying you think so -- I'm just talking out loud.)
I treat "fails" as including "cannot work".
Reasonable, but we should take care in our communications that folks understand the subcategory of failure. Having your cert validation system report a false positive is a decidedly different kind of failure from having it say "sorry, I can't operate reliably in this scenario".
And it's important that we talk about strengths and weaknesses in relation to other solutions. Currently used solutions, especially. The scenario in which all routes to a system are compromised and have always been compromised also undermines the Certificate Authority model.
Again, I think as more browsers and servers adopt SNI the case for a notary-based cert validation system grows stronger.
Disclosure: I'm greatly annoyed with the Certificate Authority model, with how it's so vulnerable for having so many CAs trusted by browsers, with how the CAs have profit motive to discourage a more democratic model so they can continue to bilk people.
Are you using Certificate Patrol as well?
There won't be a changed cert if the MITM has been in place since day one.
Ah. Yes, for the scenario when a system has never had any trustable connections to the rest of the world a "multiple views of the resource" kind of method wouldn't work. I believe you are correct.
But I don't think that's the problem that folks are trying to solve? How do I know my certificate for PayPal is legit? Or for my bank? Wikipedia? Google? For problems in this kind, Perspectives works pretty well, I think. Maybe you think so, too, since you use it in all your Firefoxes?
It also fails if you're trying to host more than one unrelated HTTPS site on port 443...
I think I see what you're talking about now. Thanks for your forbearance. The TLS encryption engages before the HTTP layer can communicate and agree on hostname, so there isn't a way to say which host the cert is for.
Yes, for the scenario in which you are accessing a virtual host via HTTPS, and the virtual host wasn't given its own IP address, and you can't use a wildcard host spec because the virtual domains being used won't fit the pattern (or it costs too much (but with a notary system we're enabling self-issued certs)), and you are running an SNI-less browser, or the server can't use or doesn't have an X509 v3 subjectAltName certificate (maybe it costs too much (but, again, we could self-issue)) and the browser can't do X509 v3 (though this is even more widespread than SNI), Perspectives fails to help. And, granted, such scenarios are not uncommon. But I don't think Perspectives needs to solve all these situations to be useful.
If you're using a modern Firefox, Safari, Chrome, or IE (that's a lot of users) and are going to a site that's not virtual hosting via the same IP or can do X509 v3 or SNI (that's a lot of sites), you're good to go. That's a pretty big chunk of secure browsing right there.
And I wouldn't say Perspectives "fails" in those scenarios. More precisely, it cannot work for those scenarios. Meaning you do not get a false sense of security -- you just can't use it then.
In any case, it can at least be used to augment SSL security. Without it, folks are just relying on the Certificate Authorities. *cringe*
Perspectives fails if the server's only connection to the Internet backbone is through a MITM.
Perspectives alerts you to the changed cert in this scenario. Have you tried it?
It also fails if you're trying to host more than one unrelated HTTPS site on port 443...
Why? I expect the notaries make HTTP requests with the "Host" header.
I've been using the following to help me validate certificates:
http://perspectives-project.org/
They have a bunch of systems that monitor SSL certs for changes. They call them "notaries". You can run a notary, too.
It helps to make sure the cert you're seeing is what everyone else is seeing and no one is doing a man-in-the-middle attack on you.
The fact that he also broke all traces of the image now kinda makes it suspicious to me.
Maybe it was something like this:
http://www.amazon.com/gp/product/images/B000001FDI/ref=dp_image_0?ie=UTF8&n=5174&s=music
Phms. They rule your hi-fi.
It's an amazingly useful protein for scientific research... Because of its research utility it's become a ubiquitous tool for molecular and cell biology. Indeed, in October of 2008 Osamu Shimomura, Martin Chalfie, and Roger Y. Tsien were awarded the Nobel Prize in Chemistry for their brilliant contributions to our modern scientific use of GFP, with The Royal Swedish Academy of Sciences calling GFP a "guiding star" and likening its research development to the invention of the microscope.
Well, maybe in the United States.
Good public transport seems like it's happened in lots of other places. I wonder if people being open to the idea helped that happen.
Interesting idea.
http://en.wikipedia.org/wiki/Lawrence_Kohlberg's_stages_of_moral_development#Stages
Un-"principled" behavior.
If Anonymity allows people to show their true self, and we dont like what we see, its not anonymity thats the problem.
That's insightful. But let's not fall into simplistic thinking. The problem doesn't exist -- things go badly by means of a variety of influences. And as you're suggesting, the lack of principled ethical motivation in people is probably a major player.