I distribute a document on a disk to the users of my systems (chain stores and suppliers), there are instructions on the disk as well as printed out on paper. This is not going to work for everybody, that's why I am leavingthesecommentshere.
Yes. But we are in a thread that discusses an "air gap" that's all. You are not in a thread that discusses how to prevent false requests from being processed. The air gap wouldn't have prevented that either and this is not what we are talking about in this specific thread.
To fix the problem that you are talking about - the false requests planted by whoever SUPPOSEDLY (and I don't believe that it is what happened there) broke into the system you need to have something else altogether. There has to be a way to verify that the request itself is legitimate. I in fact had to deal with this, I actually got a CA to generate a certificate for a company and send it to me, they didn't really know who they were talking to. This happened maybe 5 years ago and I am not going to get into specifics of what CA and what company that was.
I am only talking about having the certificate issuing computer on a network, loosely connected to the network that is connected to the Internet, only talking about not needing a 'USB data transfer' approach. So this would prevent the certificate issuing system from being compromised and that is important, since CA's private keys are there (and the signing code is there).
As to the other question of how should anybody be prevented from submitting requests to have certificates generated for domains that do not belong to that requester - I am actually quite against CAs in the first place and that's part of the reason - I don't know who submitted the request and who the hell is signing it.
there is no longer a single job that I can point at and say: gov't can do this or should do this or must do this. Anything I look at and I see gov't in there, I know it's all completely screwed up.
BTW., that's why people came to USA - for less gov't. Now they have to go to Somalia all of a sudden? I believe attempting to fix what is found locally is the first thing to do.
this is a good day for liberties, because this kind of sh...stuff exposes any type of 'authority' for what they really are, be it a gov't or any other so called authority (especially the kind that people just trust without questioning).
Since when are people just blindly trusting one another? Government like structures? Isn't this a sure way to get completely screwed by whoever you are trusting?
The entire model is wrong, of-course. There is a need for a bunch of competing systems, open, distributed, easy to verify lists, that can be compared one to another, with time stamps, with hash keys, it needs to be thought through, but there is a need. It has to be distributed so that there is no one central authority. I want to be able to check the fingerprint of a certificate against multiple competing distributed signed lists and as an admin of a system I want to be able to check what those lists maintain as fingerprint for my sites as well and quickly fix any problems if they happen. This is complicated but it will have to happen.
that's unnecessary. Build a machine with OpenBSD on it, put a write only disk into it for sharing, 2 separate network cards and then create an account for using scp between the machine and network 1 and machine and network 2. Have network 2 generate the certificates and be off the Internet, but have network 1 be on the Internet. Poll the files from the machine every once in a while.
Oh, please, do comment. I am not presenting a full solution, I am presenting the need. The need is in having a public and a free way to keep fingerprints and whether there are multiple copies with hashes that are checked one against another, whether the lists contain fingerprints as well as public certs, whether there is a way to see how long a fingerprint was in the list and if it changed at all and when and who changed it, all of it is just details.
The need is to have a distributed public and open way to keep fingerprints so that all parties - certificate owners and clients can verify those lists.
So, it boils down to risk. CAs are a million miles short of being a perfect, secure solution but they are far, far better than self-signed certificates.
- bullshit. I mistrust every single CA signed certificate and I want a fingerprint. In fact I mistrust CA generated certificates specifically because they are CA signed certificates - they are not the site operators, why are they relied upon to be honest and trustworthy in the first place? I didn't go to their site, I went to a bank site or wherever else. I don't trust the CAs and I think they are paying off the browser development teams to make it look like self signed certs are a virus.
If they're ever going to display "the padlock" they need to perform both encryption and identity checking to check off on the "due diligence"
- "due diligence" is just another way to say CYA. I am not interested in their idea of what due diligence is, I want to see the fingerprint immediately and simply to be able to compare it to a known number.
Browsers aren't written for you - they're written for non-technical users who will mostly be visiting professional websites
- and it doesn't do them any good to give them this false sense of security. It is no better than the TSA "security" theater.
If you run a website with a self-signed certificate, it means you are asking your users to unconditionally trust your identity.
- nonsense, I am providing the fingerprint information and instructions on how to compare the data when accepting the certificate.
Either get a proper certificate
- the only "proper" certificate to connect to my resources AFAIC is the one created by me and not by some untrustworthy third party.
Currently, though, they're better than nothing.
- they are worse than self signed certificates. They are masking the problem, hiding it away instead of exposing the reality to the user.
There needs to be a distributed public directory of fingerprints that is available to all for verification.
TOR based certificate comparison is a possibility, of-course this is OK if the MITM attack is against your client and is not against the server.
If the attack is against the server, so what ISP is involved somehow, then it's a much more serious issue, if all your requests/responses to that server are always modified, regardless of where the requests are originating from. This type of attack cannot be solved actually if the same ISP is used by the server for all requests. In this case it is absolutely necessary to have the correct fingerprint on hands before connecting to the server.
One way of fixing this with current technology, is to have a white list of fingerprints that is constantly monitored by the site admins who are issuing the self signed certificates to make sure that nobody modifies the list.
I wonder if it's any better than what BadAnalogyGuy would say, but I don't trust CAs, people who work there have motive and opportunity to sell you certificates that are compromised. Give me a self signed certificate and a fingerprint any day and keep your certificates sold to you by CAs.
Actually have you ever heard of MITM attacks against sites using self signed certs? Sure, it may come up, but where is any evidence? OTOH CAs selling certs is a much more likely vector of attack, as you are trusting somebody else with your certificate. I think a self signed certificate with a way to verify fingerprint is safer than a CA created certificate, there you go. I think it's not a hurdle, it's a very dangerous false feeling of security, and you don't know if CAs haven't been compromised and are not selling compromised certs actually even to banks, so that later somebody could cash out quickly and disappear with a bunch of money.
Banks and others need to think twice who their CAs are.
Are you saying the story that we are in is not good enough a reference on why you can't trust CAs selling certs? This is where you are replying right now, a story on why CAs cannot be trusted and how they can design MITM against you specifically, and you are asking me to provide more reference?
The National Emergency Centers Act or HR 645, first introduced in January 2009, mandates the establishment of âoenational emergency centersâ to be located on military installations for the purpose of providing âoetemporary housing, medical, and humanitarian assistance to individuals and families dislocated due to an emergency or major disaster,â according to the bill.
The legislation also states that the camps will be used to âoeprovide centralized locations to improve the coordination of preparedness, response, and recovery efforts of government, private, and not-for-profit entities and faith-based organizationsâ.
The bill also states that the camps can be used to âoemeet other appropriate needs, as determined by the Secretary of Homeland Security,â an open ended mandate which many fear could mean the forced detention of American citizens in the event of widespread rioting after a national emergency or total economic collapse.
I love how every time when the discussion is brought up that browsers need to stop treating https with self signed certificates worse than they treat plain http (just don't show the lock icon, show an icon for the fingerprint, which would make it easy to display the fingerprint for comparing it to a known one), some fool immediately starts talking how browsers must treat https with self signed certs worse than http because https without CA means that your session is vulnerable to the MITM.
Of-course when it is pointed out that CA does not guarantee that there is no MITM either, the discussion dies out but the opinions never change.
Well how much longer will the opinions can stay the same with all the evidence that CAs do not in fact guarantee that there is no MITM?
More importantly: who is talking about browser being responsible to figure out whether there is MITM or not with a https and a self signed cert?
Who says anything about rods? As I said: you are stuck in yesterday's technology and yesterday's thinking. This needs to get out of government jurisdiction and it needs to go back where it belongs - the private sector working on ways to deliver nuclear power in small packages.
- too bad you are an AC, it would have been great to point out the stupidity of your post in the future to nuclear car drivers.
Just because you think you know what the future holds based on the current status quo and your agenda absolutely does not mean that you are in any way right.
People said all sorts of things in the past about tech that couldn't possibly happen - why, we are not birds, we can't fly, and if we did, we'd fall out of the sky and be crashed. We can't go too fast, faster than a galloping horse, right? Because people going that fast will just go mental and die from panic.
Yes, we will have nuclear reactors in our cars. Those will be different reactors than what you are used to and crashing will not be an issue, and even if there is a crash, the nuclear reactor can be contained in a strong enough metal casing.
Nuclear is absolutely necessary and it can be used safely even now for industrial purposes (cranes/excavators/bulldozers/heavy trucks) if not in the cars right away.
We talked about it, we need technology like this here, on earth. We need private sector to get heavily involved and to make a nuclear plant that can be used in a car, in a truck, in an airplane and in a house.
Everything needs to go nuclear - if you care about the environment for real, this is the only way to go. Government subsidized systems cannot be scaled down to this level, we need private money and private hands in this and until the FUD about nuclear power stops we won't get this.
Of-course if they do design a power plant this small for other planets, the next logical step is to use it on this planet instead.
Not necessarily, if the elevator is used, then it can be accelerated downwards beyond normal free fall by motors and the air friction would be overcome really easy.
I am not talking about synchronizing only the withdrawals, that is actually done by Interac in Canada. I am talking about synchronizing all account data. But in case of the pre-paid debit cards the data can be waiting anywhere in the world, it's collected at night from whatever local branches and buffers.
Actually I don't know about this moment in time, but back when I worked for Symcor it didn't process CIBC. It processed RBC, TD and BMO, in fact they spawned the company and outsourced check processing and statement printing to them. But the checks are processed at night.
It's actually not difficult to generate 'zero-G' environment. Built a tall tower, and dig a deep vertical tunnel underneath it. Install an elevator, that can go up, then fly down in a free fall but at some point engage engines to come to a smooth stop. If the tower and the tunnel are very tall/deep, you can have a few seconds of 'zero-G' happening. Don't know how useful that is, but it can be done without jet engines.
Slashdot Mirror
I distribute a document on a disk to the users of my systems (chain stores and suppliers), there are instructions on the disk as well as printed out on paper. This is not going to work for everybody, that's why I am leaving these comments here.
Yes. But we are in a thread that discusses an "air gap" that's all. You are not in a thread that discusses how to prevent false requests from being processed. The air gap wouldn't have prevented that either and this is not what we are talking about in this specific thread.
To fix the problem that you are talking about - the false requests planted by whoever SUPPOSEDLY (and I don't believe that it is what happened there) broke into the system you need to have something else altogether. There has to be a way to verify that the request itself is legitimate. I in fact had to deal with this, I actually got a CA to generate a certificate for a company and send it to me, they didn't really know who they were talking to. This happened maybe 5 years ago and I am not going to get into specifics of what CA and what company that was.
I am only talking about having the certificate issuing computer on a network, loosely connected to the network that is connected to the Internet, only talking about not needing a 'USB data transfer' approach. So this would prevent the certificate issuing system from being compromised and that is important, since CA's private keys are there (and the signing code is there).
As to the other question of how should anybody be prevented from submitting requests to have certificates generated for domains that do not belong to that requester - I am actually quite against CAs in the first place and that's part of the reason - I don't know who submitted the request and who the hell is signing it.
well, that same fucking guy is trying to take away my dope. That's why I am for Ron Paul 2012.
there is no longer a single job that I can point at and say: gov't can do this or should do this or must do this. Anything I look at and I see gov't in there, I know it's all completely screwed up.
BTW., that's why people came to USA - for less gov't. Now they have to go to Somalia all of a sudden? I believe attempting to fix what is found locally is the first thing to do.
this is a good day for liberties, because this kind of sh...stuff exposes any type of 'authority' for what they really are, be it a gov't or any other so called authority (especially the kind that people just trust without questioning).
Since when are people just blindly trusting one another? Government like structures? Isn't this a sure way to get completely screwed by whoever you are trusting?
The entire model is wrong, of-course. There is a need for a bunch of competing systems, open, distributed, easy to verify lists, that can be compared one to another, with time stamps, with hash keys, it needs to be thought through, but there is a need. It has to be distributed so that there is no one central authority. I want to be able to check the fingerprint of a certificate against multiple competing distributed signed lists and as an admin of a system I want to be able to check what those lists maintain as fingerprint for my sites as well and quickly fix any problems if they happen. This is complicated but it will have to happen.
I would never in my entire life trust a gov't of any kind to do this work (or any other work either.)
that's unnecessary. Build a machine with OpenBSD on it, put a write only disk into it for sharing, 2 separate network cards and then create an account for using scp between the machine and network 1 and machine and network 2. Have network 2 generate the certificates and be off the Internet, but have network 1 be on the Internet. Poll the files from the machine every once in a while.
Oh, please, do comment. I am not presenting a full solution, I am presenting the need. The need is in having a public and a free way to keep fingerprints and whether there are multiple copies with hashes that are checked one against another, whether the lists contain fingerprints as well as public certs, whether there is a way to see how long a fingerprint was in the list and if it changed at all and when and who changed it, all of it is just details.
The need is to have a distributed public and open way to keep fingerprints so that all parties - certificate owners and clients can verify those lists.
Total straw man. Nobody who remotely understands the system thinks that CAs guarantee no MITM
- how about you talk to them, before talking about 'straw man'?
So, it boils down to risk. CAs are a million miles short of being a perfect, secure solution but they are far, far better than self-signed certificates.
- bullshit. I mistrust every single CA signed certificate and I want a fingerprint. In fact I mistrust CA generated certificates specifically because they are CA signed certificates - they are not the site operators, why are they relied upon to be honest and trustworthy in the first place? I didn't go to their site, I went to a bank site or wherever else. I don't trust the CAs and I think they are paying off the browser development teams to make it look like self signed certs are a virus.
If they're ever going to display "the padlock" they need to perform both encryption and identity checking to check off on the "due diligence"
- "due diligence" is just another way to say CYA. I am not interested in their idea of what due diligence is, I want to see the fingerprint immediately and simply to be able to compare it to a known number.
Browsers aren't written for you - they're written for non-technical users who will mostly be visiting professional websites
- and it doesn't do them any good to give them this false sense of security. It is no better than the TSA "security" theater.
If you run a website with a self-signed certificate, it means you are asking your users to unconditionally trust your identity.
- nonsense, I am providing the fingerprint information and instructions on how to compare the data when accepting the certificate.
Either get a proper certificate
- the only "proper" certificate to connect to my resources AFAIC is the one created by me and not by some untrustworthy third party.
Currently, though, they're better than nothing.
- they are worse than self signed certificates. They are masking the problem, hiding it away instead of exposing the reality to the user.
There needs to be a distributed public directory of fingerprints that is available to all for verification.
TOR based certificate comparison is a possibility, of-course this is OK if the MITM attack is against your client and is not against the server.
If the attack is against the server, so what ISP is involved somehow, then it's a much more serious issue, if all your requests/responses to that server are always modified, regardless of where the requests are originating from. This type of attack cannot be solved actually if the same ISP is used by the server for all requests. In this case it is absolutely necessary to have the correct fingerprint on hands before connecting to the server.
One way of fixing this with current technology, is to have a white list of fingerprints that is constantly monitored by the site admins who are issuing the self signed certificates to make sure that nobody modifies the list.
I wonder if it's any better than what BadAnalogyGuy would say, but I don't trust CAs, people who work there have motive and opportunity to sell you certificates that are compromised. Give me a self signed certificate and a fingerprint any day and keep your certificates sold to you by CAs.
Actually have you ever heard of MITM attacks against sites using self signed certs? Sure, it may come up, but where is any evidence? OTOH CAs selling certs is a much more likely vector of attack, as you are trusting somebody else with your certificate. I think a self signed certificate with a way to verify fingerprint is safer than a CA created certificate, there you go. I think it's not a hurdle, it's a very dangerous false feeling of security, and you don't know if CAs haven't been compromised and are not selling compromised certs actually even to banks, so that later somebody could cash out quickly and disappear with a bunch of money.
Banks and others need to think twice who their CAs are.
Are you saying the story that we are in is not good enough a reference on why you can't trust CAs selling certs? This is where you are replying right now, a story on why CAs cannot be trusted and how they can design MITM against you specifically, and you are asking me to provide more reference?
When asked about HR645
"Yeah, thatâ(TM)s their goal, theyâ(TM)re setting up the stage for violence in this country, no doubt about it" - Ron Paul.
The National Emergency Centers Act or HR 645, first introduced in January 2009, mandates the establishment of âoenational emergency centersâ to be located on military installations for the purpose of providing âoetemporary housing, medical, and humanitarian assistance to individuals and families dislocated due to an emergency or major disaster,â according to the bill.
The legislation also states that the camps will be used to âoeprovide centralized locations to improve the coordination of preparedness, response, and recovery efforts of government, private, and not-for-profit entities and faith-based organizationsâ.
The bill also states that the camps can be used to âoemeet other appropriate needs, as determined by the Secretary of Homeland Security,â an open ended mandate which many fear could mean the forced detention of American citizens in the event of widespread rioting after a national emergency or total economic collapse.
I love how every time when the discussion is brought up that browsers need to stop treating https with self signed certificates worse than they treat plain http (just don't show the lock icon, show an icon for the fingerprint, which would make it easy to display the fingerprint for comparing it to a known one), some fool immediately starts talking how browsers must treat https with self signed certs worse than http because https without CA means that your session is vulnerable to the MITM.
Of-course when it is pointed out that CA does not guarantee that there is no MITM either, the discussion dies out but the opinions never change.
Well how much longer will the opinions can stay the same with all the evidence that CAs do not in fact guarantee that there is no MITM?
More importantly: who is talking about browser being responsible to figure out whether there is MITM or not with a https and a self signed cert?
This cognitive dissonance needs to be eradicated.
Who says anything about rods? As I said: you are stuck in yesterday's technology and yesterday's thinking. This needs to get out of government jurisdiction and it needs to go back where it belongs - the private sector working on ways to deliver nuclear power in small packages.
There is not going to be a nuclear car. Period.
- too bad you are an AC, it would have been great to point out the stupidity of your post in the future to nuclear car drivers.
Just because you think you know what the future holds based on the current status quo and your agenda absolutely does not mean that you are in any way right.
People said all sorts of things in the past about tech that couldn't possibly happen - why, we are not birds, we can't fly, and if we did, we'd fall out of the sky and be crashed. We can't go too fast, faster than a galloping horse, right? Because people going that fast will just go mental and die from panic.
Yes, we will have nuclear reactors in our cars. Those will be different reactors than what you are used to and crashing will not be an issue, and even if there is a crash, the nuclear reactor can be contained in a strong enough metal casing.
Nuclear is absolutely necessary and it can be used safely even now for industrial purposes (cranes/excavators/bulldozers/heavy trucks) if not in the cars right away.
We talked about it, we need technology like this here, on earth. We need private sector to get heavily involved and to make a nuclear plant that can be used in a car, in a truck, in an airplane and in a house.
Everything needs to go nuclear - if you care about the environment for real, this is the only way to go. Government subsidized systems cannot be scaled down to this level, we need private money and private hands in this and until the FUD about nuclear power stops we won't get this.
Of-course if they do design a power plant this small for other planets, the next logical step is to use it on this planet instead.
It's like this - when your girlfriend or family spurns you and locks you out - you totally did not expect it, and the impact is far worse.
If you have an emotional attachment to a free online service offered by an advertising agency you have some real problems.
Which part of "Google is his family and girlfriend" did you NOT understand?
Not necessarily, if the elevator is used, then it can be accelerated downwards beyond normal free fall by motors and the air friction would be overcome really easy.
I am not talking about synchronizing only the withdrawals, that is actually done by Interac in Canada. I am talking about synchronizing all account data. But in case of the pre-paid debit cards the data can be waiting anywhere in the world, it's collected at night from whatever local branches and buffers.
Actually I don't know about this moment in time, but back when I worked for Symcor it didn't process CIBC. It processed RBC, TD and BMO, in fact they spawned the company and outsourced check processing and statement printing to them. But the checks are processed at night.
There are on-line and off-line debit cards. In Canada the on-line transactions are handled by Interac. It is a central system.
But this story is about pre-paid cards. Apparently data about purchases from these cards is synchronized in batches at night.
It's actually not difficult to generate 'zero-G' environment. Built a tall tower, and dig a deep vertical tunnel underneath it. Install an elevator, that can go up, then fly down in a free fall but at some point engage engines to come to a smooth stop. If the tower and the tunnel are very tall/deep, you can have a few seconds of 'zero-G' happening. Don't know how useful that is, but it can be done without jet engines.