Uh, you do realise who you're making fun of there, right?
Yes, I do realize that I'm making fun of somebody who believes that the purpose of SSL is to give you warm and fuzzy feelings about online shopping, that CAs certify business' good standing and integrity and then acts all astonished when somebody dares to point out that SSL is supposed to protect against interception/manipulation of data in transit. And then bolsters his position by pointing out his presence at some conferences where SSL was a subject.
He was helping create the web while you were still in nappies.
Well, as long as he enjoyed the nibbles and the drinks...
If I were to design such a craft, it would 1) be very slow and as near to silent as possible. 2) contain absolutely no stealth technologies that might give enemy engineers clues about our radar abilities, and 3) implement an FPGA based one time pad data encryption system to transmit recon data to the nearby recon team.
Ths way if the craft crashes, gets shot down, or captured the expense of replacement is 1) very low due to nearly 100% plastic construction and cheap electronics. 2) data forensically uninteresting from either an engineering pov or from a data espianage point of view. 3) cannot be used to break mission critical data encryption technologies, due to 1:1 one time pad pairings, with quite possibly cheap commercial encryption methods. (256AES, etc.) By the time it is recovered and studied, that pad is black listed as belonging to an mia drone.
Good design ideas, but I don't think you quite grasp the concept of one-time-pad:
AES256 is not a one-time pad but a symmetric key algorithm
No need to blacklist a one-time pad if compromised, as you are supposed to use it only one time anyways. That's why it's called one-time pad after all...: Reusing a one-time pad compromises its integrity. However keys for AES would indeed need to get blacklisted if caught.
Then how do you distinguish those vendors "who want to cheat" from those that are just innocently pointing out that the spec'ed maximal speed can only be reached if the disk is able to supply it too (which would be another reason to say "up to").
Let me explain. I have been working on Web security now for 19 years.
How cute. I have been working on Web security for 19 years and one day.
I was present at the original meetings at which the SSL system was proposed,
Well, actually I was the one who wrote the paper!
I convened several of the relevant meetings.
Yes, and I convened the others.
At no time was government wiretap a design consideration for SSL. NEVER.
Hmm, yes it was. Don't you remember, at the third meeting. But maybe you missed that bit as you were far too busy chatting up that cute blonde who was sitting next to you.
In fact to claim this was totally ridiculous since at the time we were fighting a running battle with the FBI and the NSA who were trying to stop us using strong cryptography at all. The original SSL design was limited to 40 bits and was very clearly crackable.
Yeah, I remember. At many meetings we had guys in dark suits and dark sunglasses, with silly earpieces, and whom nobody knew...
SSL is not designed to be wiretap proof, my proposal and the EIT proposal were stronger in that regard.
Indeed. The main purpose of SSL was to cure AIDS. That's why there were so many people in white bodysuits with silly mouth protection.
But at the time the criteria was whether shopping online could be made as safe as shopping in a store.
Indeed. Shoulder surfing by nearby shoppers while you enter your credit card pin is a huge concern... And those strange side panels placed around the pin keyboard are not to protect it from view of shoulder surfers, but are actually a quality seal awarded by the BBB to shops which have no complaints against them.
That was the design criteria by which SSL was judged and the design criteria it passed (after they eventually hired some competent crypto people).
Yeah, indeed. Initially they only had you.
I was the person who stated the design criteria at the meeting.
And I was the one in the back row asking "but can we have a pony with it".
The only way this would go unnoticed is if they had the MITM already in place before hotmail or gmail existed.
... because else the early adopters will suddenly see that the certificate changed at the moment where they introduced this surveillance.
And because it is impossible to probe remotely whether a browser already has the certificate cached or not, these countries can't even selectively switch on the MITM for the "new" users.
2) Pop a huge warning if the cert changes, even if the CA signs the new one. This is the really important part.
There are firefox extensions which do just that: Certificate Patrol. If a certificate changes without reason (i.e. while still being far from expiration), a warning pops up.
However, the problem with this approach is again stupidity of the webmail operators and ignorance how certificates work.
Some large webmail providers (yahoo, google,...) who have load-balanced banks of servers sometimes have half of their servers with one certificate, and the other half with another (possibly even signed by another CA...), resulting in lots of false alarms while you unknowingly switch between both, triggering lots of false "Certificate patrol" alarms diluting their value...
Gosh, how hard is it to switch over all servers at once? Does it really have to take a week?
The SSH model works great: connect to a site once; verify the fingerprint once if you consider a MITM to be a reasonable concern; cache the key and know that forever after you're connecting to the same site as you did the first time.
You can (theoretically) do that too with SSL. Connect to the site, you get a certificate warning. Instead of blindly accepting the certificate, read the SHA1 fingerprint (which is displayed in the dialog box asking for acceptance), and call the helpdesk of the business with which your interacting to verify that it is the correct one. After accepting the certificate once, your browser now has it in its cache, and in knows forever (or rather: until expiration) that you're connecting to the same site as you did the first time.
Why "theoretically"? Even assuming the helpdesk wouldn't be overloaded by such requests, there's the obvious problem that the understanding about how certificates work is so poor among the general population that the helpdesk is likely to just go: "fingerprint? what's that? But don't worry: you trusted us enough to open a bank account with us, so you can trust our bank account too".
If people knew how this stuff worked, you'd get a small card with the certificate fingerprint on it from your bank when you open an account, so you could verify it the first time you connect to your bank's site.
But it does not provide a basis for trust because mere holdership of a DNS domain does not mean you are trustworthy.
It does not provide a cure for cancer either...
See my CAA and ESRV Internet drafts.
Maybe you should try submitting a paper to the Lancet too. With a little bit of luck you might catch a peer-reviewer off guard amazed to notice that cancer starts with CA.
No seriously, the "trust" in "trusted third party" has nothing to do with the trust that you put in the second party (i.e. the server or business with which you are communicating). It has all about to do with the trust you put in the third party (the certification agency), that it correctly does its job (only giving certificates to properly identified entities and appropriately securing their infrastructure so that hackers and spies can't just "help themselves"). The threat that SSL certificates are supposed to protect against is wiretapping, not rogue businesses. I'm sure, all of those shady banks that failed in the 2008/2009 crisis had valid SSL certificates, and rightly so!
Unfortunately marketers have latched on to the catchy word "trust", completely muddying any understanding about whom your supposed to trust. A certificate is not a badge of honor any more than a passport is. Both are just pieces of identification.
How would they know whom to sue...? Guess what would happen if MAFIAA goons in dark suits hang around schoolyards trying to observe whether kids are trading USB sticks...
That's the advantage of sneakernet: it can't be tapped, it can only be observed directly, to great risk to the observer...
The only protection comes from tight timing windows, and who's louder.
... and that's where TEP kicks in: it depends on the ability to use periods of silence to communicate. The MITM cannot drown out the router's "energy" packets by silence.
Still doesn't make it right to get a secret court order to inflict willful damage on a person's property. And then media act all astonished when somebody decide to takes his rights, his rifle, and a couple of grenades in his own hands.
If justice is so obviously corrupted, it is no longer justice. And people will go back to doing what they were doing before there was a functioning justice system in place.
Slashdot Mirror
Uh, you do realise who you're making fun of there, right?
Yes, I do realize that I'm making fun of somebody who believes that the purpose of SSL is to give you warm and fuzzy feelings about online shopping, that CAs certify business' good standing and integrity and then acts all astonished when somebody dares to point out that SSL is supposed to protect against interception/manipulation of data in transit. And then bolsters his position by pointing out his presence at some conferences where SSL was a subject.
He was helping create the web while you were still in nappies.
Well, as long as he enjoyed the nibbles and the drinks ...
But apart from that, whatever.
Or are they just not pulling their weight?
If I were to design such a craft, it would 1) be very slow and as near to silent as possible. 2) contain absolutely no stealth technologies that might give enemy engineers clues about our radar abilities, and 3) implement an FPGA based one time pad data encryption system to transmit recon data to the nearby recon team.
Ths way if the craft crashes, gets shot down, or captured the expense of replacement is 1) very low due to nearly 100% plastic construction and cheap electronics. 2) data forensically uninteresting from either an engineering pov or from a data espianage point of view. 3) cannot be used to break mission critical data encryption technologies, due to 1:1 one time pad pairings, with quite possibly cheap commercial encryption methods. (256AES, etc.) By the time it is recovered and studied, that pad is black listed as belonging to an mia drone.
Good design ideas, but I don't think you quite grasp the concept of one-time-pad:
Then how do you distinguish those vendors "who want to cheat" from those that are just innocently pointing out that the spec'ed maximal speed can only be reached if the disk is able to supply it too (which would be another reason to say "up to").
Microsoft tax.
Let me explain. I have been working on Web security now for 19 years.
How cute. I have been working on Web security for 19 years and one day.
I was present at the original meetings at which the SSL system was proposed,
Well, actually I was the one who wrote the paper!
I convened several of the relevant meetings.
Yes, and I convened the others.
At no time was government wiretap a design consideration for SSL. NEVER.
Hmm, yes it was. Don't you remember, at the third meeting. But maybe you missed that bit as you were far too busy chatting up that cute blonde who was sitting next to you.
In fact to claim this was totally ridiculous since at the time we were fighting a running battle with the FBI and the NSA who were trying to stop us using strong cryptography at all. The original SSL design was limited to 40 bits and was very clearly crackable.
Yeah, I remember. At many meetings we had guys in dark suits and dark sunglasses, with silly earpieces, and whom nobody knew...
SSL is not designed to be wiretap proof, my proposal and the EIT proposal were stronger in that regard.
Indeed. The main purpose of SSL was to cure AIDS. That's why there were so many people in white bodysuits with silly mouth protection.
But at the time the criteria was whether shopping online could be made as safe as shopping in a store.
Indeed. Shoulder surfing by nearby shoppers while you enter your credit card pin is a huge concern... And those strange side panels placed around the pin keyboard are not to protect it from view of shoulder surfers, but are actually a quality seal awarded by the BBB to shops which have no complaints against them.
That was the design criteria by which SSL was judged and the design criteria it passed (after they eventually hired some competent crypto people).
Yeah, indeed. Initially they only had you .
I was the person who stated the design criteria at the meeting.
And I was the one in the back row asking "but can we have a pony with it".
I've got some good news for you: Günter von Gravenreuth is dead!. So stop worrying.
The errant iPhone, which went missing in San Francisco's Mission district in late July...
It would have been more appropriate if the iPhone had been lost in a bar in the Castro district instead...
And because it is impossible to probe remotely whether a browser already has the certificate cached or not, these countries can't even selectively switch on the MITM for the "new" users.
2) Pop a huge warning if the cert changes, even if the CA signs the new one. This is the really important part.
There are firefox extensions which do just that: Certificate Patrol. If a certificate changes without reason (i.e. while still being far from expiration), a warning pops up.
However, the problem with this approach is again stupidity of the webmail operators and ignorance how certificates work.
Some large webmail providers (yahoo, google, ...) who have load-balanced banks of servers sometimes have half of their servers with one certificate, and the other half with another (possibly even signed by another CA...), resulting in lots of false alarms while you unknowingly switch between both, triggering lots of false "Certificate patrol" alarms diluting their value...
Gosh, how hard is it to switch over all servers at once? Does it really have to take a week?
The SSH model works great: connect to a site once; verify the fingerprint once if you consider a MITM to be a reasonable concern; cache the key and know that forever after you're connecting to the same site as you did the first time.
You can (theoretically) do that too with SSL. Connect to the site, you get a certificate warning. Instead of blindly accepting the certificate, read the SHA1 fingerprint (which is displayed in the dialog box asking for acceptance), and call the helpdesk of the business with which your interacting to verify that it is the correct one. After accepting the certificate once, your browser now has it in its cache, and in knows forever (or rather: until expiration) that you're connecting to the same site as you did the first time.
Why "theoretically"? Even assuming the helpdesk wouldn't be overloaded by such requests, there's the obvious problem that the understanding about how certificates work is so poor among the general population that the helpdesk is likely to just go: "fingerprint? what's that? But don't worry: you trusted us enough to open a bank account with us, so you can trust our bank account too".
If people knew how this stuff worked, you'd get a small card with the certificate fingerprint on it from your bank when you open an account, so you could verify it the first time you connect to your bank's site.
But it does not provide a basis for trust because mere holdership of a DNS domain does not mean you are trustworthy.
It does not provide a cure for cancer either...
See my CAA and ESRV Internet drafts.
Maybe you should try submitting a paper to the Lancet too. With a little bit of luck you might catch a peer-reviewer off guard amazed to notice that cancer starts with CA.
No seriously, the "trust" in "trusted third party" has nothing to do with the trust that you put in the second party (i.e. the server or business with which you are communicating). It has all about to do with the trust you put in the third party (the certification agency), that it correctly does its job (only giving certificates to properly identified entities and appropriately securing their infrastructure so that hackers and spies can't just "help themselves"). The threat that SSL certificates are supposed to protect against is wiretapping, not rogue businesses. I'm sure, all of those shady banks that failed in the 2008/2009 crisis had valid SSL certificates, and rightly so!
Unfortunately marketers have latched on to the catchy word "trust", completely muddying any understanding about whom your supposed to trust. A certificate is not a badge of honor any more than a passport is. Both are just pieces of identification.
That's the advantage of sneakernet: it can't be tapped, it can only be observed directly, to great risk to the observer...
Hopefully you still keep a backup at home, or there goes your lifetime data collection if ever you get mugged...
because the copyright owners would object.
And, so what? Copyright holders were probably not too happy either when we traded music cassettes in the schoolyard...
... should be safer than nukes too!
Why the hell would they do that?
But this is wrong - the man in the middle may simply be listening.
Yeah right, and the purpose of an SSL certificate is to prove that you are a honorable person or business.
(in which case the appropriate term should be "Man All Over You")
Also known as a DSK attack...
The only protection comes from tight timing windows, and who's louder.
... and that's where TEP kicks in: it depends on the ability to use periods of silence to communicate. The MITM cannot drown out the router's "energy" packets by silence.
Then please post.
More like the Slashdot effect currently...
of the judge?
If justice is so obviously corrupted, it is no longer justice. And people will go back to doing what they were doing before there was a functioning justice system in place.
Does it break patents and copyright in the Netherlands?
No. It can't break patents in the Netherlands, because there is no such thing as software patents in the Netherlands.