No, that's hard-core capitalism - supply and demand; all that jazz. Apple doesn't see any value in his product (exploit) so they aren't willing to pay. Somebody else could be willing to pay for what he has so he could sell it to them instead.
Normally when there is much more supply than demand then manufacturer needs to start advertising to make sure that the potential buyers are aware that product exists. When there is more demand but almost no supply, then potential buyers will advertise to every potential manufacturer (or author in this case) that they are willing to pay for certain product, if anybody has it.
Entry barrier to computing has gone down, a lot, in past 10 years. Also like you said back then most of the disks were shipped unformatted thus most of the people knew they'd need to format them before use.
Nowadays flash drives are predominantly shipped formatted so people assume that they work once you plug them in. If they don't, people assume that they are broken.
One option is to move the write protection tab to 'LOCK' when card is full. Only move it back to 'WRITE' when you transfer the data to PC and clear the card.
Who cares where the form came from?!?! Are you serious? Hmm. Well, there's the problem. If the casual user has decided to enter secret information into forms of unknown origin, then it doesn't really matter if the form's recipient uses a trusted key, since he doesn't know who the recipient is (until it's too late).
Did you actually read what I wrote?
Whole form is completely irrelevant in this context. It could be that I append the same information to URL as GET parameters.
Remember that the form and post target are not necessarily on the same server. It could be that the attack can be staged to one server but not on the other.
If I'm not warned about self-signed certificate before submitting data, how should I know that the server certificate is self-signed before posting the data? Distinction between casual user and security expert goes out of the window at the same moment when you start accepting any self-signed certificate without warning.
With the current implementation you need to compromise the form and replace you post target with your own non-https server. This information would be available to the user before entering any information on the form. Your casual user probably wouldn't pay any attention to this but somebody else might. Proposal to accept self-signed certificates without warning would make sure that nobody could tell the difference - only way to detect forged (sorry, self-signed) certificate would be to submit the data to attacker who staged the MitM.
Remind me again what would be the benefits of accepting self-signed certificates without warning and how they outweigh the potential problems that might be introduced?
Padlock icon or lack of it is only visible to the user after connection has been established and data was sent. Who cares if the connection which was used fetch the <FORM> from the server was encrypted or not, the interesting part is what happens with the data that I entered to that form and then submitted over connection that I thought would be secure. If I can see that the ACTION part of the form is over HTTPS then I know that the data will only be sent to the server holding a valid certificate. Proposal to automatically accept invalid (sorry, self-signed) certificates would turn this to something comparable to Schrödinger's cat; I can't know whether the connection was authenticated without sending the data.
Most users probably don't choose to use SSL. Usually it's the server that decides it by redirecting or posting to a secure page (bad idea, anyway!) If the user types in, "mybank.com" into their address bar, the default is to try http on port 80 first. A man in the middle can intercept this, and then it's game over, anyway.
If you rely on the end-user for security, you might as well give up.
If I submit a form over HTTPS I expect the connection to be authenticated and encrypted. If somebody manages to stage a MitM attack on me, it'll be detected immediately as I'm using SSL. But what you are saying is that browser should just accept the invalid certificate and submit the data anyway. It could be that the attacker couldn't compromise the form I was filling in as it came from different server or from local disk.
Dude, you have to be on crack.
Even if uninformed public would somehow benefit (which I highly doubt) from this 'solution' of yours, it would still hurt those that actually know what they are doing. It would also make sure that those few users that actually choose to use SSL couldn't use it for purposes it was intended.
What your problem is is that for some reason you think there's just one problem possible on the internet: Talking to the WRONG person.
No, you are missing the point here. SSL is intended to address both issues, authentication and encryption. And we are talking about SSL here, right?
All most self-signed certificate using sites want is to eliminate plain text conversations, just plain simple encryption, they make no claims about security, they don't want a "green bar", they just don't want to be treated as worse than HTTP.
In that case SSL is a wrong tool for them.
If you want to have only encryption feel free to use (or define) a different protocol for it, but don't break the existing one that works pretty well for its intended purpose.
I agree that there are situations when encryption without authentication is sufficient but it still doesn't justify butchering perfectly good solution for completely different problem.
The difference is that when user is using HTTP there is no expectation of security while using SSL one assumes that connection is encrypted and authenticated.
You are talking about encryption while the error message is about authentication. While these two are closely related in this context, they are different things.
SSL without proper chain of trust (authentication) is secure against eavesdropping but not MitM. Properly implemented SSL is resistant against both. SSL was designed for both authentication and encryption so it shouldn't automatically degrade to encryption-only.
The difference is that admins of the SSL site want that their users make sure that they are connecting to the correct server. It's the admin of the site who is requesting the browser to flag up any potential problem with the connection. If they wouldn't care, they wouldn't have used SSL in the first place.
Precisely. OTP is supposed to be a protection against password compromise. "Got my password? No prob! The one you got will never work again anyway."
That's only true for eavesdropping, not MITM. In case of MITM password doesn't make it to the destination server and thus doesn't get removed from the list of valid passwords. MITM attacker could just show you forged "Login failed" page and use the password later on.
OTP passwords aren't usually time limited; you can use them whenever you choose to do so.
Properly implemented secure tokens (SecurID and such) dish out passwords that are valid only at certain moment and are also single use. If the captured password is received by the legimate server it becomes useless. Only thing attacker could do is to stage a MITM, capture the password and prevent it from being delivered to server and then use it immediately for his own purposes.
People seem to think that NAT was the reason why we haven't ran out of addresses yet.
I'd dare to say that CIDR played even bigger role than NAT when it comes to shaping the internet to the form we see it today. CIDR was elegant solution to a problem that shouldn't have existed in the first place.
No, Y2K was a very serious problem that was avoided at the last minute at great expense.
I'd not put it that way. Yes, it was serious issue in some cases but most of the serious issues were solved in advance.
Most of the action during '99 was just cashing the customers who wanted to have "Y2K compliant" sticker attached to every kettle and pot. Sure, there were some surprises but not much.
It would also help if the ISPs that actually provide IPv6 connectivity would also provide transition tools like 6to4 HTTP proxies.
If that would be done, most of the home users with dual stacks (I *think* Vista comes with dual stack preferring IPv6 when AAAA records are present, can anyone confirm?) wouldn't even notice that all their HTTP traffic is via IPv6 while their torrents are still downloaded using IPv4.
It would also be nice if hosting companies would start implementing IPv6 on their shared servers. All the users hosted on those shared servers would be able to provide IPv6 content to their customers without any extra effort.
1) UI component for user to remove the cached credentials from browser cache. 2) Web server to be able to remove cached credentials by using Javascript or something similar.
I was quite surprised to find that neither one was logged to Firefox Bugzilla as enhancement.
To me "cloud" in network diagrams has nothing to do with Internet. I use clouds to remove irrelevant clutter from the diagrams. It can be any network (or part of one) which internal layout isn't relevant for that diagram. It could be corporate backbone, Internet, PSTN, whatever.
Then again, that's just how to visualize something on a diagram and I'd not part of the network or internet "cloud".
The problem is websites that want 'pretty' login screens with text boxes for input, instead of using the builtin authentication methods available over HTTP.
Exactly, why to expose your own code to all the automatic probes that go around the internet when you could use "well-tested" webserver code instead? If there are problems with webserver authentication code somebody might patch it but if it's your own code nobody but you will be auditing it.
Sure, your authenticated users could still exploit your code once authenticated but that would at least limit the number of attempts.
It's not uncommon at all for this to be done on unencrypted pages (even some banks have made that mistake).
It's worth noting that HTTP Basic Authentication just base64 encodes the passwords but doesn't encrypt them. HTTP Digest Access hashes the passwords but is vulnerable to Man-in-the-middle attacks so you need to use HTTPS anyway.
Yes but the proof RIAA would bring to the court is not just the IP/MAC address combination. That's just a pretext to grab a random student who's IP happens to match, seize his computer and find thousands of MP3 files in the shared folders of a P2P application.
That's exactly the point. It has been established that the IP address on its own is not enough as it can not be tied to single user/pc. That's the reason why they try to use IP/MAC pair to single out the computer they want to confiscate.
IP/MAC is just as reliable as IP address on its own.
Over their cell network, I don't think this is an unreasonable stance for them to take.
Agreed. It's just the way they did it. If I would be their customer, I'd not be pissed about them imposing limits as it probably is justifiable. On the other hand, I'd sue the fuckers to oblivion for really misleading marketing.
Tax appraisers work for the government and thus get a bit more leeway than your normal person.
At least in all the countries that I have lived at none of the government employees get any leeway without search warrant signed by proper authorities.
You want to inspect my house for tax fraud? Sure, ask my permission or get a warrant.
Same goes with utility workers, supers and whatnot - no access unless authorized by me. There is no superintendent that will go into my apartment without my permission. If I ask somebody to fix something then I grant them permission to do so. But I don't grant my cable/water/telephone company permission to enter my apartment to fix something without asking me first. If they want to be proactive, excellent, but they need to ask me before going into my apartment.
If your government gives some kind of a special all-access pass to all those random people just because of their job, I suggest that you either do something to change it or move to a different country.
I kind of a like the way Apache config files are structured - most of the global directives are just name/value pairs on the top level while some of the directives, like vhost related items, go to hierarchical containers.
Slashdot Mirror
That's precisely the attitude of a black hat.
No, that's hard-core capitalism - supply and demand; all that jazz. Apple doesn't see any value in his product (exploit) so they aren't willing to pay. Somebody else could be willing to pay for what he has so he could sell it to them instead.
Normally when there is much more supply than demand then manufacturer needs to start advertising to make sure that the potential buyers are aware that product exists. When there is more demand but almost no supply, then potential buyers will advertise to every potential manufacturer (or author in this case) that they are willing to pay for certain product, if anybody has it.
Entry barrier to computing has gone down, a lot, in past 10 years. Also like you said back then most of the disks were shipped unformatted thus most of the people knew they'd need to format them before use.
Nowadays flash drives are predominantly shipped formatted so people assume that they work once you plug them in. If they don't, people assume that they are broken.
One option is to move the write protection tab to 'LOCK' when card is full. Only move it back to 'WRITE' when you transfer the data to PC and clear the card.
200 containers
Would that be 20' or 40' containers?
I think they just want to make sure they can keep overselling their bandwidth
Do you really think that it is possible to run a profitable ISP without overselling?
Who cares where the form came from?!?! Are you serious? Hmm. Well, there's the problem. If the casual user has decided to enter secret information into forms of unknown origin, then it doesn't really matter if the form's recipient uses a trusted key, since he doesn't know who the recipient is (until it's too late).
Did you actually read what I wrote?
Whole form is completely irrelevant in this context. It could be that I append the same information to URL as GET parameters.
Remember that the form and post target are not necessarily on the same server. It could be that the attack can be staged to one server but not on the other.
If I'm not warned about self-signed certificate before submitting data, how should I know that the server certificate is self-signed before posting the data? Distinction between casual user and security expert goes out of the window at the same moment when you start accepting any self-signed certificate without warning.
With the current implementation you need to compromise the form and replace you post target with your own non-https server. This information would be available to the user before entering any information on the form. Your casual user probably wouldn't pay any attention to this but somebody else might. Proposal to accept self-signed certificates without warning would make sure that nobody could tell the difference - only way to detect forged (sorry, self-signed) certificate would be to submit the data to attacker who staged the MitM.
Remind me again what would be the benefits of accepting self-signed certificates without warning and how they outweigh the potential problems that might be introduced?
You don't get it, do you?
Padlock icon or lack of it is only visible to the user after connection has been established and data was sent. Who cares if the connection which was used fetch the <FORM> from the server was encrypted or not, the interesting part is what happens with the data that I entered to that form and then submitted over connection that I thought would be secure. If I can see that the ACTION part of the form is over HTTPS then I know that the data will only be sent to the server holding a valid certificate. Proposal to automatically accept invalid (sorry, self-signed) certificates would turn this to something comparable to Schrödinger's cat; I can't know whether the connection was authenticated without sending the data.
Most users probably don't choose to use SSL. Usually it's the server that decides it by redirecting or posting to a secure page (bad idea, anyway!) If the user types in, "mybank.com" into their address bar, the default is to try http on port 80 first. A man in the middle can intercept this, and then it's game over, anyway.
If you rely on the end-user for security, you might as well give up.
If I submit a form over HTTPS I expect the connection to be authenticated and encrypted. If somebody manages to stage a MitM attack on me, it'll be detected immediately as I'm using SSL. But what you are saying is that browser should just accept the invalid certificate and submit the data anyway. It could be that the attacker couldn't compromise the form I was filling in as it came from different server or from local disk.
Dude, you have to be on crack.
Even if uninformed public would somehow benefit (which I highly doubt) from this 'solution' of yours, it would still hurt those that actually know what they are doing. It would also make sure that those few users that actually choose to use SSL couldn't use it for purposes it was intended.
What your problem is is that for some reason you think there's just one problem possible on the internet: Talking to the WRONG person.
No, you are missing the point here. SSL is intended to address both issues, authentication and encryption. And we are talking about SSL here, right?
All most self-signed certificate using sites want is to eliminate plain text conversations, just plain simple encryption, they make no claims about security, they don't want a "green bar", they just don't want to be treated as worse than HTTP.
In that case SSL is a wrong tool for them.
If you want to have only encryption feel free to use (or define) a different protocol for it, but don't break the existing one that works pretty well for its intended purpose.
I agree that there are situations when encryption without authentication is sufficient but it still doesn't justify butchering perfectly good solution for completely different problem.
Hell no!
The difference is that when user is using HTTP there is no expectation of security while using SSL one assumes that connection is encrypted and authenticated.
You are talking about encryption while the error message is about authentication. While these two are closely related in this context, they are different things.
SSL without proper chain of trust (authentication) is secure against eavesdropping but not MitM. Properly implemented SSL is resistant against both. SSL was designed for both authentication and encryption so it shouldn't automatically degrade to encryption-only.
The difference is that admins of the SSL site want that their users make sure that they are connecting to the correct server. It's the admin of the site who is requesting the browser to flag up any potential problem with the connection. If they wouldn't care, they wouldn't have used SSL in the first place.
Precisely. OTP is supposed to be a protection against password compromise. "Got my password? No prob! The one you got will never work again anyway."
That's only true for eavesdropping, not MITM. In case of MITM password doesn't make it to the destination server and thus doesn't get removed from the list of valid passwords. MITM attacker could just show you forged "Login failed" page and use the password later on.
OTP passwords aren't usually time limited; you can use them whenever you choose to do so.
Properly implemented secure tokens (SecurID and such) dish out passwords that are valid only at certain moment and are also single use. If the captured password is received by the legimate server it becomes useless. Only thing attacker could do is to stage a MITM, capture the password and prevent it from being delivered to server and then use it immediately for his own purposes.
Which government would that be?
And NAT is a problem masquerading as a solution.
People seem to think that NAT was the reason why we haven't ran out of addresses yet.
I'd dare to say that CIDR played even bigger role than NAT when it comes to shaping the internet to the form we see it today. CIDR was elegant solution to a problem that shouldn't have existed in the first place.
No, Y2K was a very serious problem that was avoided at the last minute at great expense.
I'd not put it that way. Yes, it was serious issue in some cases but most of the serious issues were solved in advance.
Most of the action during '99 was just cashing the customers who wanted to have "Y2K compliant" sticker attached to every kettle and pot. Sure, there were some surprises but not much.
Very true.
It would also help if the ISPs that actually provide IPv6 connectivity would also provide transition tools like 6to4 HTTP proxies.
If that would be done, most of the home users with dual stacks (I *think* Vista comes with dual stack preferring IPv6 when AAAA records are present, can anyone confirm?) wouldn't even notice that all their HTTP traffic is via IPv6 while their torrents are still downloaded using IPv4.
It would also be nice if hosting companies would start implementing IPv6 on their shared servers. All the users hosted on those shared servers would be able to provide IPv6 content to their customers without any extra effort.
That is very true.
In general there are two things missing:
1) UI component for user to remove the cached credentials from browser cache.
2) Web server to be able to remove cached credentials by using Javascript or something similar.
I was quite surprised to find that neither one was logged to Firefox Bugzilla as enhancement.
To me "cloud" in network diagrams has nothing to do with Internet. I use clouds to remove irrelevant clutter from the diagrams. It can be any network (or part of one) which internal layout isn't relevant for that diagram. It could be corporate backbone, Internet, PSTN, whatever.
Then again, that's just how to visualize something on a diagram and I'd not part of the network or internet "cloud".
The problem is websites that want 'pretty' login screens with text boxes for input, instead of using the builtin authentication methods available over HTTP.
Exactly, why to expose your own code to all the automatic probes that go around the internet when you could use "well-tested" webserver code instead? If there are problems with webserver authentication code somebody might patch it but if it's your own code nobody but you will be auditing it.
Sure, your authenticated users could still exploit your code once authenticated but that would at least limit the number of attempts.
It's not uncommon at all for this to be done on unencrypted pages (even some banks have made that mistake).
It's worth noting that HTTP Basic Authentication just base64 encodes the passwords but doesn't encrypt them. HTTP Digest Access hashes the passwords but is vulnerable to Man-in-the-middle attacks so you need to use HTTPS anyway.
Yes but the proof RIAA would bring to the court is not just the IP/MAC address combination. That's just a pretext to grab a random student who's IP happens to match, seize his computer and find thousands of MP3 files in the shared folders of a P2P application.
That's exactly the point. It has been established that the IP address on its own is not enough as it can not be tied to single user/pc. That's the reason why they try to use IP/MAC pair to single out the computer they want to confiscate.
IP/MAC is just as reliable as IP address on its own.
People should understand that MAC address is no more permanent than IP address is.
Unfortunately they don't.
Over their cell network, I don't think this is an unreasonable stance for them to take.
Agreed. It's just the way they did it. If I would be their customer, I'd not be pissed about them imposing limits as it probably is justifiable. On the other hand, I'd sue the fuckers to oblivion for really misleading marketing.
Tax appraisers work for the government and thus get a bit more leeway than your normal person.
At least in all the countries that I have lived at none of the government employees get any leeway without search warrant signed by proper authorities.
You want to inspect my house for tax fraud? Sure, ask my permission or get a warrant.
Same goes with utility workers, supers and whatnot - no access unless authorized by me. There is no superintendent that will go into my apartment without my permission. If I ask somebody to fix something then I grant them permission to do so. But I don't grant my cable/water/telephone company permission to enter my apartment to fix something without asking me first. If they want to be proactive, excellent, but they need to ask me before going into my apartment.
If your government gives some kind of a special all-access pass to all those random people just because of their job, I suggest that you either do something to change it or move to a different country.
[...]then sell the book rights to "How You Can Legally Steal $30 Million from VC Suckers".
No, it would be more like "How do you get VC suckers to give you $30 Million". And that, my dear friend, is an art that I'd love to master.
XML sucks for configuration files, to be honest.
Agreed.
I kind of a like the way Apache config files are structured - most of the global directives are just name/value pairs on the top level while some of the directives, like vhost related items, go to hierarchical containers.