It's not illegal to blog about how you're going to shoot up the school; you're only committing a crime if you actually do it.
The crime would be "wasting police time", "false bomb threats", which are punishable in many jurisdictions.
If the threats are credible enough, police are forced to react, costing considerable amounts of time and money, which is no joking matter, even if the threat is not acted upon.
Just imagine if such idle threats were legal: children would phone in these every day, in order to get their morning off...
I'm not talking about an individual's mail; I'm talking about those new account confirmation emails many forums send out, that you have to acknowledge before you can post.
Odds are a rejection mail is going into the bitbucket.
On a properly configured automailer, any error messages are supposed to go to the administrator. How else would he be made aware that something is amiss?
Like I want to give www.randomforum.com my phone number? Like they have an administrator that active?
In case of an automailer, if there is trouble, probability is that the trouble is related to the software they are using. If the administrator manually mails you using his normal MTA, chances are good that this time it succeeds.
And if the automailer is so badly set up that it can't set up a proper reply, are you really trusting that outfit that it handles all other aspects of the service well? (such as not communicating your e-mail to a spammer anyways...)
If the new request is outright rejected, how am I supposed to get my confirmation email?
The same thing would happen as in the situation where you wouldn't expect mail from that source: the sender would get the bounce, which would contain a reason why the mail was rejected (such and such keyword in mail, no text,...), he then would change his mail to match, and try again.
And if he was unable to comply, he would use a different channel (i.e. phone) to communicate with you.
As for Phishing, banks have moved to authentication systems that use graphics on the page to tell you that the password-entry box you're looking at is legit. If you don't see your predetermined secret glyph, you don't enter your password. And the glyph isn't sent until your browser and the server are connected by SSL, so it can't be sniffed and hacked into a phishing site.
... and what if the phishing site connects to the real bank (via SSL...) in order to get the relevant glyphs?
And it isn't sent unless your browser already has a cookie identifying it as having been validated previously, using a secret-question protocol.
Ok, so this one's secure, as the browser wouldn't send the bank's cookies to the phisher's site (which has a plausible looking, but different URL).
If you deleted the cookie, you go through the secret-question routine again.
... which will alert you that is something amiss if you didn't actually delete your cookies, which is good. But, if for security reasons (... to protect against other kinds of threats, such as tracking by advertisers...) you've set your browser to consider all cookies as session cookies, then you will get this dialog every single time, making it useless as a warning against phishing. O, and the phishers will have the correct "secret question", because he just connects to the real bank site.
Ok, in real life, the bank's system would probably grow suspicious if it got lots of connection attempts for different users from a single IP, but in this day and age of botnets, this can easily be worked around by the attacker.
For example with ticketpod.nl, if you order 4 tickets, you get 4 separate tickets, each with its own bar-code, rather than one master ticket with a count.
1. download random pic from Internet.
2. put it on stick, along with Virus
3. infect kiosk
4. from now on, kiosks substitutes customers photos with "random internet pic" from step 1 somewhere between the time the order has been validated, and when it will be printed.
5....
6. Sit back and watch the fun as customer comes back to pick up his photos...
Unless you need to look up "Tiananmen Square" every 10 minutes, it really shouldn't be a problem.
And even then, it wouldn't be a problem. As a simple anti-spam deterrent, we've got "Remember Tienanmen" in the greeting string of our sendmail. But we still get loads of Chinese spam.
A couple of years back, there were loads of lists of open proxies circulating around. Many were located in China. Out of curiosity, I connected through one of these, and started googling for Tienanmen, Tibet, and other assorted keywords. All sites were accessible... So, if there is a Great Wall of Fire, it must be very leaky.
A friend of mine is working for a supplier of automotive parts with (at the time) two branch offices in Luxembourg, and one in the United States (Detroit).
All 3 are linked together with a VPN.
And just after the planes struck the buildings on 911, the VPN with Detroit mysteriously went down. Unencrypted connections continued working as if nothing happened (so it's not a case of a router being located physically in WTC, or whatever). A couple of days later, all was back to normal. No explanation ever followed.
This guy was talking about a computer lab. I get the impression that Huey, Duey, Louie, Barney, Smarmey, Charley, Blarney, Indigo Montarney etc will get particularly bothersome to keep tabs on as a convention. Why not B2R22Cad4
You know, if you are the kind of person that prefers numbers over pronouncable names, computers also have IP addresses. Just use those, and leave the hostnames for the rest of us...
My wife forgot to lock our house door one night and we were burglarized.
More like "my wife forgot to lock our bedroom door one night, and a thief got in and stole the jewelry out of the nightstand. I didn't know that our front door locks could be so easily picked and that we were supposed to lock the doors within our house as well."
If voice-mail are "protected" by caller-id, most users (... and apparently the telco too...) will think that an "additional" protection (the password) is not needed.
The system designers should either use ANI (less easily spoofable), or not rely on any caller identification at all, rather than giving a "false sense of security" both to their customers and to the employees who configure the default password.
if you don't put a password on it, you're just as much to blame
Do you lock the door to each room in your house?
No, you don't need to, you just lock the front door (and other exterior doors).
Same thing here: customers (and apparently the telco too) believed that caller-id was protection enough, so no password is needed.
The real scandal here is why isn't caller-id unspoofable? If this hack would only be possible from professional equipment or from PABX'es connected via a trunk line, I might understand.
But accessible from every handset? The designers of such system must be crazy!
... alone is vulnerable to man-in-the-middle attacks. As the session keys change each time, even when no attack happens, this means that any mitm attack would go unnoticed.
Session keys (by definition...) also change for PKI-based encryption, but there they are derived from the public/private key pairs which do not change.
...when it's a known-safe server accessed only by a few authorised users?
Certificates aren't supposed to protect against server compromise (and they don't...), they are supposed to protect against compromise of the communication infrastructure (routers, DNS). Your server can be as secure as you want, as long as your clients connect to it over the public internet, then you are vulnerable to man-in-the-middle attacks if you don't use real certificates (or verify the fingerprint)
SNI isn't the only way to handle SSL-virtual hosts. Wildcard certificates (*.example.com) and Subject alt names (*.foo.com,*.bar.com) are other ways to achieve the same goal (... and work on any web server, even if the server doesn't support SNI)
You can get certificates with multiple (non-related) names ("Subject Alt Names") nowadays. These are supported by cacert.org and probably also by other CA's if you pay the right coin (... and if you can show that you are a legitimate agent for all of these domain names, of course...).
Moreover with the most recent mod_ssl (or with any version of mod_gnutls) Apache supports SNI, which allows it to pick amongst several certificates the one that corresponds to the client's request.
That's not what certificates are for (at least not when they were designed initially...).
Certificates are there to assure you that you are indeed "directly" connected to your own site, rather than through a snooping proxy that your employer (or whoever else sits between your client and your server) may have set up.
I hope you did at least verify the certificate's fingerprint the first time you connected to your server from that client...
using a multi step login process over SSL using an invalid certificate, where the user is presented with pre-answered challenge questions, and then presented with their predefined message/image to establish "trust" before the login credentials are sent effectively mimics the protection of trusting a 3rd party to validate the SSL certificate as authentic.
No, the Mitm would just display the predefined message/image in the same way as it would display the rest of the page's content, and the user would be none the wiser.
I should know, a while back I helped a friend set up an mitm to spy his wife's Yahoo password, and everything showed up perfectly, including the "sign-in seal". The only thing that she could have noticed was that the URL was http instead of https, and that there was no lock (because Yahoo did have a real certificate which we couldn't spoof). But the contents of the page was perfect.
Lesson learned: web sites should teach their users to watch for the real tell-tale signs of attack (lock icon, correct URL, certificate warnings), rather than lull them in a false sense of security using seals and other gimmicks.
Friends... or work colleagues. Homophobe, or suspected homophobe (when you try to avoid the subject as much as possible, and all you have to go about is weird quips and off-color jokes)
Slashdot Mirror
It's not illegal to blog about how you're going to shoot up the school; you're only committing a crime if you actually do it.
The crime would be "wasting police time", "false bomb threats", which are punishable in many jurisdictions.
If the threats are credible enough, police are forced to react, costing considerable amounts of time and money, which is no joking matter, even if the threat is not acted upon.
Just imagine if such idle threats were legal: children would phone in these every day, in order to get their morning off...
I'm not talking about an individual's mail; I'm talking about those new account confirmation emails many forums send out, that you have to acknowledge before you can post.
Odds are a rejection mail is going into the bitbucket.
On a properly configured automailer, any error messages are supposed to go to the administrator. How else would he be made aware that something is amiss?
Like I want to give www.randomforum.com my phone number? Like they have an administrator that active?
In case of an automailer, if there is trouble, probability is that the trouble is related to the software they are using. If the administrator manually mails you using his normal MTA, chances are good that this time it succeeds.
And if the automailer is so badly set up that it can't set up a proper reply, are you really trusting that outfit that it handles all other aspects of the service well? (such as not communicating your e-mail to a spammer anyways...)
If the new request is outright rejected, how am I supposed to get my confirmation email?
The same thing would happen as in the situation where you wouldn't expect mail from that source: the sender would get the bounce, which would contain a reason why the mail was rejected (such and such keyword in mail, no text, ...), he then would change his mail to match, and try again.
And if he was unable to comply, he would use a different channel (i.e. phone) to communicate with you.
And even if you don't, firefox (old version...) would autocomplete to what you've entered previous times.
As for Phishing, banks have moved to authentication systems that use graphics on the page to tell you that the password-entry box you're looking at is legit. If you don't see your predetermined secret glyph, you don't enter your password. And the glyph isn't sent until your browser and the server are connected by SSL, so it can't be sniffed and hacked into a phishing site.
... and what if the phishing site connects to the real bank (via SSL...) in order to get the relevant glyphs?
And it isn't sent unless your browser already has a cookie identifying it as having been validated previously, using a secret-question protocol.
Ok, so this one's secure, as the browser wouldn't send the bank's cookies to the phisher's site (which has a plausible looking, but different URL).
If you deleted the cookie, you go through the secret-question routine again.
... which will alert you that is something amiss if you didn't actually delete your cookies, which is good. But, if for security reasons (... to protect against other kinds of threats, such as tracking by advertisers...) you've set your browser to consider all cookies as session cookies, then you will get this dialog every single time, making it useless as a warning against phishing. O, and the phishers will have the correct "secret question", because he just connects to the real bank site.
Ok, in real life, the bank's system would probably grow suspicious if it got lots of connection attempts for different users from a single IP, but in this day and age of botnets, this can easily be worked around by the attacker.
London? Shouldn't that be the other way round?
Well, Great Britain has... and they have far less people than China.
If this was indeed in the news, do you have any citation from a (reputable) source about this MITM datacenter that was housed in or near the WTC?
For example with ticketpod.nl, if you order 4 tickets, you get 4 separate tickets, each with its own bar-code, rather than one master ticket with a count.
As for everyone else trying to sell tickets, they're scalpers and who cares what they think?
What about groups of friends going to a concert, but one of them buying the tickets for all, in order to make sure to get seats together?
1. download random pic from Internet. ...
2. put it on stick, along with Virus
3. infect kiosk
4. from now on, kiosks substitutes customers photos with "random internet pic" from step 1 somewhere between the time the order has been validated, and when it will be printed.
5.
6. Sit back and watch the fun as customer comes back to pick up his photos...
Unless you need to look up "Tiananmen Square" every 10 minutes, it really shouldn't be a problem.
And even then, it wouldn't be a problem. As a simple anti-spam deterrent, we've got "Remember Tienanmen" in the greeting string of our sendmail. But we still get loads of Chinese spam.
A couple of years back, there were loads of lists of open proxies circulating around. Many were located in China. Out of curiosity, I connected through one of these, and started googling for Tienanmen, Tibet, and other assorted keywords. All sites were accessible... So, if there is a Great Wall of Fire, it must be very leaky.
All 3 are linked together with a VPN.
And just after the planes struck the buildings on 911, the VPN with Detroit mysteriously went down. Unencrypted connections continued working as if nothing happened (so it's not a case of a router being located physically in WTC, or whatever). A couple of days later, all was back to normal. No explanation ever followed.
This guy was talking about a computer lab. I get the impression that Huey, Duey, Louie, Barney, Smarmey, Charley, Blarney, Indigo Montarney etc will get particularly bothersome to keep tabs on as a convention. Why not B2R22Cad4
You know, if you are the kind of person that prefers numbers over pronouncable names, computers also have IP addresses. Just use those, and leave the hostnames for the rest of us...
My wife forgot to lock our house door one night and we were burglarized.
More like "my wife forgot to lock our bedroom door one night, and a thief got in and stole the jewelry out of the nightstand. I didn't know that our front door locks could be so easily picked and that we were supposed to lock the doors within our house as well."
If voice-mail are "protected" by caller-id, most users (... and apparently the telco too...) will think that an "additional" protection (the password) is not needed.
The system designers should either use ANI (less easily spoofable), or not rely on any caller identification at all, rather than giving a "false sense of security" both to their customers and to the employees who configure the default password.
Caller ID spoofing is nothing new.
If this is such old news, then why o hell hasn't it been fixed yet? Why is it still so easy to pull off these shenanigans?
if you don't put a password on it, you're just as much to blame
Do you lock the door to each room in your house?
No, you don't need to, you just lock the front door (and other exterior doors).
Same thing here: customers (and apparently the telco too) believed that caller-id was protection enough, so no password is needed.
The real scandal here is why isn't caller-id unspoofable? If this hack would only be possible from professional equipment or from PABX'es connected via a trunk line, I might understand.
But accessible from every handset? The designers of such system must be crazy!
... Diffie Hellman ...
... alone is vulnerable to man-in-the-middle attacks. As the session keys change each time, even when no attack happens, this means that any mitm attack would go unnoticed.
Session keys (by definition...) also change for PKI-based encryption, but there they are derived from the public/private key pairs which do not change.
...when it's a known-safe server accessed only by a few authorised users?
Certificates aren't supposed to protect against server compromise (and they don't...), they are supposed to protect against compromise of the communication infrastructure (routers, DNS). Your server can be as secure as you want, as long as your clients connect to it over the public internet, then you are vulnerable to man-in-the-middle attacks if you don't use real certificates (or verify the fingerprint)
...SSL-virtual hosts, called SNI
SNI isn't the only way to handle SSL-virtual hosts. Wildcard certificates (*.example.com) and Subject alt names (*.foo.com,*.bar.com) are other ways to achieve the same goal (... and work on any web server, even if the server doesn't support SNI)
Moreover with the most recent mod_ssl (or with any version of mod_gnutls) Apache supports SNI, which allows it to pick amongst several certificates the one that corresponds to the client's request.
verify organizational integrity
That's not what certificates are for (at least not when they were designed initially...).
Certificates are there to assure you that you are indeed "directly" connected to your own site, rather than through a snooping proxy that your employer (or whoever else sits between your client and your server) may have set up.
I hope you did at least verify the certificate's fingerprint the first time you connected to your server from that client...
using a multi step login process over SSL using an invalid certificate, where the user is presented with pre-answered challenge questions, and then presented with their predefined message/image to establish "trust" before the login credentials are sent effectively mimics the protection of trusting a 3rd party to validate the SSL certificate as authentic.
No, the Mitm would just display the predefined message/image in the same way as it would display the rest of the page's content, and the user would be none the wiser.
I should know, a while back I helped a friend set up an mitm to spy his wife's Yahoo password, and everything showed up perfectly, including the "sign-in seal". The only thing that she could have noticed was that the URL was http instead of https, and that there was no lock (because Yahoo did have a real certificate which we couldn't spoof). But the contents of the page was perfect.
Lesson learned: web sites should teach their users to watch for the real tell-tale signs of attack (lock icon, correct URL, certificate warnings), rather than lull them in a false sense of security using seals and other gimmicks.
In Illinois, it's legal to fuck your congressman's wife so long as you don't pay her for it.
... but if you did, would you be charged for prostitution or for illegal campaign funding?
Friends... or work colleagues. Homophobe, or suspected homophobe (when you try to avoid the subject as much as possible, and all you have to go about is weird quips and off-color jokes)