It's the most-likely situation where they'll actually search your laptop and where you have no interest in divulging your encryption keys.
Most "cybercrime" is a lot harder to notice (particularly by border guards doing cursory searches as you pass through) and tends to have evidence elsewhere other than the suspect's laptop.
As it stands now, it's fairly reasonable if you're sitting on a good position on a network link to MitM every single HTTPS communication that chooses to use a self-signed certificate. (To avoid detection and relieve yourself of some work, you might want to avoid trying to MitM legitimate certs.)
Granted, if nearly every HTTP communication was replaced with HTTPS using self-signed certs, they'd need to upgrade their hardware a bit.
Currently a number of Tor exit nodes attempt to MitM either every self-signed HTTP or every HTTPS (not caring much about detection, apparently), and these nodes see quite a bit of traffic.
If everyone used legitimate HTTPS, it would also prevent an attacker on your local network from actively modifying data (for example, inserting malicious scripts into your Web pages).
If everyone used encryption with self-signed certs and Tor, they'd get to find out how common MitM attacks are.
I'm not sure what your point is. You can accept self-signed certificates in Firefox 3, they just changed the UI.
By having to add specific exceptions, you can cache all of the self-signed certs you choose to trust.
People who complain so much about this seem to want self-signed certs to be usable. I'm not sure why. I suppose they'll claim that they want their communication to be encrypted, but that just indicates they're missing the whole point. The encryption provided by self-signed SSL is worthless: if someone could read the unencrypted traffic, they could MitM your SSL connection.
See, you have a link to the schedule already. They mention the researcher's name. Maybe you could look up what talk it was?
Oh, hell, I'll do it for you. "Mike Perry; 365-Day: Active https cookie hijacking."
This is the "presentation on hijacking your sessions if you ever access a site over plain-text (non-SSL), and putting the password page on SSL doesn't help" that you mention, but I'd be surprised if you saw the presentation. The first few slides were about how this is *not* sidejacking -- the attack you described. This attack is similar, but more subtle, and doesn't require the user to ever intentionally communicate over unsecured HTTP with the target. It does still require physical access to the network (e.g., an open wireless access point).
Actually, the problem isn't even dropping back to a normal HTTP session. That's old news. The current problem is that it doesn't set the secure bit on the session cookie, so an attacker can induce it to be sent over HTTP even if all of your intentional communication with Gmail is over HTTPS.
This is true, except for every wireless access point the attacker can access -- like the ones where people sit in a coffee shop and check their e-mail.
The summary (and many, many replies) have it all wrong. The point is not that you need to be encrypting all of your traffic to Gmail (for example) with SSL.
The need for SSL-encrypting your session was known with sidejacking. If you use SSL for credential exchange but not for the whole session, your session cookie is transmitted in the clear, and an attacker can sniff it and use your session (as the cookie acts temporarily as a credential). Encrypting the whole session with SSL prevents this. This is well-known at this point.
The subject of this talk was not sidejacking. If the site (Gmail) does not set the secure bit on the session cookie, then your session cookie can be transmitted in the clear, even if all of your intentional communication with Gmail is over SSL! An attacker need only inject a link to the appropriate domain (e.g., mail.google.com) in some other page you request, and the cookie will be sent with that request over HTTP. Only by marking the cookie as secure will the browser refuse to send it over HTTP.
Google, etc., were notified of this vulnerability a year ago and have not acted on it. Someone with bad intentions could implement it easily using the description of the vulnerability anyway -- a publicly-available working tool will highlight the importance of fixing this problem.
Only my most introductory undergraduate classes were structured around a particular textbook. I think that was mostly because the classes were very large and they wanted to have some level of homogeneity across years.
Beyond that, most classes had a single recommended textbook and sometimes an optional one or two. People generally thought that the "recommended textbook" absolutely had to be purchased (and sometimes they were right, such as when it was heavily used for homework problems). A handful of classes had no real textbook.
You're probably thinking of strict atheist philosophies, which don't permit much spirituality, than atheism in general, which only rejects the existence of any god or gods. (Strictly speaking, an atheist can be religious, provided the religion doesn't assert the existence of a god.)
Viewing people as entities that are meaningful after their death (and thus are buried as a rite or ritual and not simply as a sanitary measure) is spirituality.
No, "atheism" refers to believing that there are no god or gods.
You are correct that an atheist can still be a spiritual person, both in the more typical interpretation of "spiritual" and in the more general sense. However, it has nothing to do with the Christian god specifically.
And not giving out personal information is the best way to prevent it from being stolen.
Clearly attempt to prevent things like cross-site scripting, sidejacking, and unencrypted transfer of credentials are all pointless -- we should just teach the "right approach" of not using computers. No loss there!
The whole thing would go a lot faster if they'd just tell us who they were going to select as their various advisors and whether or not they were going to listen to them.
Hopefully not too many people are deluded into thinking that the President actually makes his own decisions, rather than leaning heavily on advisors and other departments.
Slashdot Mirror
At 0.001% of Nanos affected, it's probably more likely that your plane's engine bursts into flame than a Nano brought onto the flight.
Border guards aren't required to have a warrant to search items that you are bringing into or removing from the country.
You're thinking of the fourth amendment. This is the fifth amendment, under which you cannot be compelled to testify against yourself.
It's the most-likely situation where they'll actually search your laptop and where you have no interest in divulging your encryption keys.
Most "cybercrime" is a lot harder to notice (particularly by border guards doing cursory searches as you pass through) and tends to have evidence elsewhere other than the suspect's laptop.
As it stands now, it's fairly reasonable if you're sitting on a good position on a network link to MitM every single HTTPS communication that chooses to use a self-signed certificate. (To avoid detection and relieve yourself of some work, you might want to avoid trying to MitM legitimate certs.)
Granted, if nearly every HTTP communication was replaced with HTTPS using self-signed certs, they'd need to upgrade their hardware a bit.
Currently a number of Tor exit nodes attempt to MitM either every self-signed HTTP or every HTTPS (not caring much about detection, apparently), and these nodes see quite a bit of traffic.
If everyone used legitimate HTTPS, it would also prevent an attacker on your local network from actively modifying data (for example, inserting malicious scripts into your Web pages).
If everyone used encryption with self-signed certs and Tor, they'd get to find out how common MitM attacks are.
No, "SSL-only" means setting the secure bit on their session cookie, which they do not do.
I'm not sure what your point is. You can accept self-signed certificates in Firefox 3, they just changed the UI.
By having to add specific exceptions, you can cache all of the self-signed certs you choose to trust.
People who complain so much about this seem to want self-signed certs to be usable. I'm not sure why. I suppose they'll claim that they want their communication to be encrypted, but that just indicates they're missing the whole point. The encryption provided by self-signed SSL is worthless: if someone could read the unencrypted traffic, they could MitM your SSL connection.
See, you have a link to the schedule already. They mention the researcher's name. Maybe you could look up what talk it was?
Oh, hell, I'll do it for you. "Mike Perry; 365-Day: Active https cookie hijacking."
This is the "presentation on hijacking your sessions if you ever access a site over plain-text (non-SSL), and putting the password page on SSL doesn't help" that you mention, but I'd be surprised if you saw the presentation. The first few slides were about how this is *not* sidejacking -- the attack you described. This attack is similar, but more subtle, and doesn't require the user to ever intentionally communicate over unsecured HTTP with the target. It does still require physical access to the network (e.g., an open wireless access point).
Actually, the problem isn't even dropping back to a normal HTTP session. That's old news. The current problem is that it doesn't set the secure bit on the session cookie, so an attacker can induce it to be sent over HTTP even if all of your intentional communication with Gmail is over HTTPS.
This is true, except for every wireless access point the attacker can access -- like the ones where people sit in a coffee shop and check their e-mail.
The summary (and many, many replies) have it all wrong. The point is not that you need to be encrypting all of your traffic to Gmail (for example) with SSL.
The need for SSL-encrypting your session was known with sidejacking. If you use SSL for credential exchange but not for the whole session, your session cookie is transmitted in the clear, and an attacker can sniff it and use your session (as the cookie acts temporarily as a credential). Encrypting the whole session with SSL prevents this. This is well-known at this point.
The subject of this talk was not sidejacking. If the site (Gmail) does not set the secure bit on the session cookie, then your session cookie can be transmitted in the clear, even if all of your intentional communication with Gmail is over SSL! An attacker need only inject a link to the appropriate domain (e.g., mail.google.com) in some other page you request, and the cookie will be sent with that request over HTTP. Only by marking the cookie as secure will the browser refuse to send it over HTTP.
If I can't sniff your traffic, you don't need to encrypt it in the first place.
If I can sniff it, I can probably modify it.
In that case, I can launch a man-in-the-middle attack.
If you're accepting self-signed certificates, there's no way for you to easily differentiate my false certificate from the site's real one.
Self-signed certificates are dangerous because they give the user the impression that they have gained some security when they have not.
Google, etc., were notified of this vulnerability a year ago and have not acted on it. Someone with bad intentions could implement it easily using the description of the vulnerability anyway -- a publicly-available working tool will highlight the importance of fixing this problem.
Only my most introductory undergraduate classes were structured around a particular textbook. I think that was mostly because the classes were very large and they wanted to have some level of homogeneity across years.
Beyond that, most classes had a single recommended textbook and sometimes an optional one or two. People generally thought that the "recommended textbook" absolutely had to be purchased (and sometimes they were right, such as when it was heavily used for homework problems). A handful of classes had no real textbook.
Graduate classes were all more as you describe.
If they really needed to do their job quickly, they'd do it on dedicated hardware that could handle 128-bit numbers natively.
You're probably thinking of strict atheist philosophies, which don't permit much spirituality, than atheism in general, which only rejects the existence of any god or gods. (Strictly speaking, an atheist can be religious, provided the religion doesn't assert the existence of a god.)
Viewing people as entities that are meaningful after their death (and thus are buried as a rite or ritual and not simply as a sanitary measure) is spirituality.
No, "atheism" refers to believing that there are no god or gods.
You are correct that an atheist can still be a spiritual person, both in the more typical interpretation of "spiritual" and in the more general sense. However, it has nothing to do with the Christian god specifically.
And not giving out personal information is the best way to prevent it from being stolen.
Clearly attempt to prevent things like cross-site scripting, sidejacking, and unencrypted transfer of credentials are all pointless -- we should just teach the "right approach" of not using computers. No loss there!
And not driving is the best way to stay out of automobile accidents.
Unless you want to, you know, get somewhere public transportation won't get you.
I'm not sure what "public transportation" is in the sex part of this analogy, but I'm pretty sure it's as unsatisfying as the local bus.
I actually get my MP3s off the intarwebs for free and then mail the artists the 10 cents per album they would have gotten if I bought the CD.
If you were going to do this properly, you could at least pick the correct logical fallacy than just selecting the one that everyone knows about.
The whole thing would go a lot faster if they'd just tell us who they were going to select as their various advisors and whether or not they were going to listen to them.
Hopefully not too many people are deluded into thinking that the President actually makes his own decisions, rather than leaning heavily on advisors and other departments.
Figuring that out is left as an exercise to the reader. :-)