October 2007: Tooth ache when drinking cold water or beer.
November 2007 & January 2008: Dentist: "Oh, it's nothing, you just have extra sensitive teeth. Have some fluor! If it was an infection, it would hurt always and not just when drinking cold.".
February 2008. Suddenly, one day, tooth ache stops. Hooray! But what are are all these blisters and itching all over my mouth? And why is my tongue dark green? Fortunately, there's Hextril Mouthwash...
March 2008. A big lump develops near the "formerly" cumbersome tooth
March-May 2008: Root canal! (yes, this took 5 visits over the course of almost 2 months to get done)
October 2008: Same tooth almost completely destroyed
Ocotber 2008: Dentist: "Wanna have a crown?" Me: "Sure, if it'll solve the problem for good. What will be the price?" Dentist: "700 €" Me: "Gasp! But I guess I'll have no choice"
November 2008: After 5 more visits including several botched attempts due to a very mis-shapen tooth opposite the troublesome one, I finally have a brand new tooth 17
January 2009: Me: "hey, this chocolate is not supposed to have nuts. So what's that hard bit?" "Oh, it's the crown!"
Notably, no version of IE on XP supports it. Some sites may not care, but most will.
We're speaking about security here. Who cares about IE or Windows? If you've got a virus on your machine, all transport-level security won't help, as the malware will intercept your data before it's encrypted. Or it'll just add a bogus CA to IE's certificate store.
The answer, as best I could understand, was the risk of a perception by customers that installing our CA cert would somehow weaken the security of their browsers.
And your customers would be right. Who tells that you wouldn't use your CA to sign a fake bank certificate and use it to spy on your customers' transaction? So from the customer's point of view, it does indeed weaken their browsers.
However, IF ssl established encryption, then virtual host, then authenticity (to varying degrees of confidence as configured by the user's trust settings), https wouldn't require a seperate IP per virtual host anymore.
It doesn't. There are several approaches to the problem:
subjectAltNames and wildcard certificates. Nowadays, certificates can carry multiple site names. Just make a certificate containing all site names (not supported by all CA's, but Entrust and CaCert do)
SNI (Server Name Indication). This allows the webserver to use a different certificate for different virtual hosts. Soon to be supported by mod_ssl, but already supported (for several years) by mod_gnutls
. Most clients (browsers) today support it out of the box, only Konqueror seems to be lagging behind, alas!
There are cases (such as a private lan to an internal server) where authentication (particularly CLIENT authentication) w/o encryption may be reasonable.
Client is almost never authenticated via SSL anyways. You're right about the private LAN. Easyest LAN-based attacks are passive eavesdropping, rather than active Mitm. But in most other cases, encryption without authentication of the peer just doesn't make sense. But in a private LAN, you're probably in a position of setting up your own CA anyways, as basically you control your browser's CA lists.
If I am contacting https://argleblargle.nu/ for the first time, I don't have any Idea who that is even if they are authenticated.
But you do know that it's argleblargle.nu, rather than somebody who managed to poison DNS or hijack your router.
When he told me (paraphrased) that they "KNOW the entity they give a cert to isn't committing fraud because they have to sign a LEGAL DOCUMENT that says they aren't!"
A marketroid spouting nonsense about technical matters. What else is new?
Of course, you and I know that a CA is supposed to verify identity of the party that they're issuing a certificate to, not its trustworthiness (unless they're issuing a sub-CA certificate, but that's a different matter). Much misunderstanding does indeed come from this misconception of a CA's role.
Of course, https is screwed up anyway because of the way it munges security and authenticity together. Ideally, browser and server should immediately do a key exchange, then once the connection is encrypted, perform optional authentication after the browser sends the host field. The lock icon should indicate encryption and authentication separately.
Ok, now you seem to fall prey to the same misconception. Without being sure about the identity of the party your communicating with, there can be no security. Think about it.
You could be talking to an interloper who does nothing else than pass your messages to your bank, and your bank's messages to you. And take notes, of course.
That's what's is called a man-in-the-middle-attack. And apparently they're not just the stuff of some James-Bond movie, but occasionally do happen in real life. Here, a prankster was setting up an open Wifi honeyspot and rigged it to eavesdrop on SSL communications. Of course, Firefox caught the bad certificates, which the victim dutifully shrugged off and filed as a bug. Haha. Or maybe it was a trawl, she did indeed mention that she was "bumming off an unsecured Wifi access point" a leetle bit too early in the thread...
Without public key verification (either by certificate, or by manually comparing fingerprints) there can be no security against such attacks.
You Sir have just re-invented CaCert. CaCert is a certification authority which operates by a web-of-trust model: users certify each other after seeing id, and only users having gathered a minimum amount of assurance points can get a certificate.
Unfortunately, CaCert is not trusted by the browsers (such as Mozilla or Konqueror), who seem to be more hung up about expensive audits and pompous root key signing ceremonies.
Other CA's, such as Comodo/CertStar or RapidSSL/GeoTrust don't seem to have any problems being blessed by browsers though. Thanks to these fly-by-nighters it's still very easy to mount an Mitm attack using your open Wifi honeypot, which will be undetectable, unlike this poser here.
Not sure what you are going on about, I just tried to helpfully point out that many browsers actually do supply the reason(s) why a certificate was rejected in their popup message, even if there are multiple reasons. That way, you don't need to mess with the clock, because the browser will tell you whether the fact that the certificate was expired was the only reason why it was rejected, or whether there were other reasons as well.
We once had a case where a server had a certificate with 3 problems at once: expired, self-signed and mismatched hostname. Browsers pointed out all 3 problems together.
Well, it should barf on any site signed by RapidSSL, even legitimate ones. Does anybody have an example of a site signed by RapidSSL?
Another way to test it would be would to set up your own CA using openssl, import it into your browser, then create an MD5-signed sub CA certificate for it, and finally use the sub CA to make a certificate for your website. But does anybody know how to convince openssl to use MD5 rather than SHA-1 for signing certificates?
You'd of course have to set the clock on your machine back to the time where the certificate was valid if you wanted to see the proof of concept.
Many browsers display the reason(s) why a certificate is rejected. So, in this case, it would say "Expired certificate and invalid CA in chain of trust"
After reading this article, I think that RapidSSL/FreeSSL should stop issuing certificates altogether.
Indeed. This MD5 issue is not the only problem that RapidSSL has. Their biggest issue is that they don't do any effort whatsoever to verify the requestor's identity. All the requestor has to do is:
Supply a phone number under which he can be reached
Prove that he can read e-mail sent to the domain to which he wants a certificate
The phone number is not verified, and using the number of a pre-paid mobile plan (or a callable phone booth) will work just fine.
Two may be a little bit tougher, until you think against what a certificate is supposed to protect: man-in-the-middle attacks.
So if the perp can get close enough to his target to mount a man-in-the-middle attack, he can also intercept mails sent to that target. Or, if the target is a webmail provider (hotmail,...), he only needs to create one account out of the many allowed on the service.
Contrast this with other certification authorities, such as CA-Cert, which require a face-to-face verification with at least two volunteers which are trained and can be held responsible for errors.
Granted, domain ownership verification is not any more stringent than with RapidSSL (except for a smaller list of possible admin adresses), but at least in case of fraud, CaCert will have a chain of assurers leading to the perp in case of fraud, whereas RapidSSL would only have the number of a phone booth in a shady neighborhood.
We prefer these orbits because they best serve the equatorial regions we have monopolized.
I know I should be feeding a troll, but the reason for putting most communications' satellites into equatorial orbits is that these are the only orbits that can be geostationary (satellite stays put relatively to the surface).
You really prefer to be able to leave your antenna's pointed to the same spot in the sky, rather than having to equip it with a motor that follows the satellite around.
If I received papers via Facebook I'd just ignore them, as there is not way anyone else could know whether I received them, or that the account was actually me.
But what if the lawyers posted the papers to your wall, rather than your inbox? In that case, all your "friends" would know too, and if you weren't careful with whom you befriended on facebook, some might rat you out (confirming that (1) it was indeed you, and (2) that you logged on, which they know because you accepted that nice christmas ornament they sent you).
Here in Luxembourg, Luxtrust likes to give technical support via Facebook and other chat sites, even when the original request was submitted via e-mail.
But I've got the impression that they do it for exactly the opposite reason: because such replies do not create a legal liability.
As you can imagine, the chances of you disappearing from society and leaving no trace of how to contact you with employers, neighbors, family, and friends is fairly small...unless you're running from something.
I know a guy who thought it smart to just "disappear" for a year, touring the world.
When he came back, his large real estate holdings were foreclosed, because there was problems with some tenants who failed to pay their utility bills and just left (some even taking the keys with them...). The company that my friend had hired to look after the building failed to do anything about the situation, so the city moved to confiscate the building in order to pay the bills.
"Fortunately" California's prop 8 guarantees that you can't have an even worse situation, i.e. one where only the social security number would be different...
Re:What we need now is a good Newsreader.
on
64-Bit Java For Linux
·
· Score: 0, Flamebait
Running Windows Usenet clients in Wine is one solution, but I'd really like a FOSS solution.
That must be the lamest troll I've seen in ages...
Anybody got any suggestions? I'm an old fart and won't give up my Usenet until they pry it from my cold, dead fingers.
Do you also go to the nearest Democratic convention if you want to get a gun? Do you got to a disco if you want to listen to classical music?
Teachers have to have the right to confiscate property.
They may have the right to confiscate property, but they don't have the right to slander people.
If you do think that slander is ok, I'd suggest that the kid asks for a private meeting with the teacher about this whole Linux CD issue.
After the meeting, the kid can then run around and claim that much more interesting things happened during that meeting than actually happened. Should be fun.
A wire transfer typically costs $25 outgoing and $12 incoming
Even Fortis isn't that expensive... Try more something more like â3. And you have the appropriate plan ("Global Club"), you get a number of free wire transfers per quarter.
and you need to know the receiver's bank account # & routing number.
Which surprise most people do. Bank routing numbers (BIC) are published by the banks themselves, and account numbers of people wanting to receive such transfers (shops, charities, admistrations...) are public too. And if it's family or friends, they can give you their account number easily. Oh, and usually the account number is only enough if you want to put money on an account. If you want to remove money from an account, you'll need something more, such as a password, a signature plus id, etc.
I seriously doubt that it is used that much by most people.
Well, here in Europe, it is used very commonly, for all kinds of things.
The only possibility I see is a machine used for sustaining life (obviously for the user of the gun, not the recipient of the bullet).
"Investigation, replacement, modification, or support of the anatomy or a physiological process" also looks about right to me. Nowhere did it say that the process (life) needed to be modified for the better, and ending a process certainly looks like one kind of modification to me.
Slashdot Mirror
It doesn't have muscles, chest hair and beautiful pitch black (why be PC about hair color when you forgot about sexual orientation?) hair.
Yeah, teeth, a never-ending source of fun...
But then, a small mouth will provide you a good excuse to escape some cumbersome bed-time tasks...
I'd like to put the little bastard in a sack, and toss the sack in a river, ..
O the irony. That used to be the punishment for not ratting out your "customers"...
Notably, no version of IE on XP supports it. Some sites may not care, but most will.
We're speaking about security here. Who cares about IE or Windows? If you've got a virus on your machine, all transport-level security won't help, as the malware will intercept your data before it's encrypted. Or it'll just add a bogus CA to IE's certificate store.
The answer, as best I could understand, was the risk of a perception by customers that installing our CA cert would somehow weaken the security of their browsers.
And your customers would be right. Who tells that you wouldn't use your CA to sign a fake bank certificate and use it to spy on your customers' transaction? So from the customer's point of view, it does indeed weaken their browsers.
However, IF ssl established encryption, then virtual host, then authenticity (to varying degrees of confidence as configured by the user's trust settings), https wouldn't require a seperate IP per virtual host anymore.
It doesn't. There are several approaches to the problem:
. Most clients (browsers) today support it out of the box, only Konqueror seems to be lagging behind, alas!
There are cases (such as a private lan to an internal server) where authentication (particularly CLIENT authentication) w/o encryption may be reasonable.
Client is almost never authenticated via SSL anyways. You're right about the private LAN. Easyest LAN-based attacks are passive eavesdropping, rather than active Mitm. But in most other cases, encryption without authentication of the peer just doesn't make sense. But in a private LAN, you're probably in a position of setting up your own CA anyways, as basically you control your browser's CA lists.
If I am contacting https://argleblargle.nu/ for the first time, I don't have any Idea who that is even if they are authenticated.
But you do know that it's argleblargle.nu, rather than somebody who managed to poison DNS or hijack your router.
When he told me (paraphrased) that they "KNOW the entity they give a cert to isn't committing fraud because they have to sign a LEGAL DOCUMENT that says they aren't!"
A marketroid spouting nonsense about technical matters. What else is new?
Of course, you and I know that a CA is supposed to verify identity of the party that they're issuing a certificate to, not its trustworthiness (unless they're issuing a sub-CA certificate, but that's a different matter). Much misunderstanding does indeed come from this misconception of a CA's role.
Of course, https is screwed up anyway because of the way it munges security and authenticity together. Ideally, browser and server should immediately do a key exchange, then once the connection is encrypted, perform optional authentication after the browser sends the host field. The lock icon should indicate encryption and authentication separately.
Ok, now you seem to fall prey to the same misconception. Without being sure about the identity of the party your communicating with, there can be no security. Think about it.
You could be talking to an interloper who does nothing else than pass your messages to your bank, and your bank's messages to you. And take notes, of course.
That's what's is called a man-in-the-middle-attack. And apparently they're not just the stuff of some James-Bond movie, but occasionally do happen in real life. Here, a prankster was setting up an open Wifi honeyspot and rigged it to eavesdrop on SSL communications. Of course, Firefox caught the bad certificates, which the victim dutifully shrugged off and filed as a bug. Haha. Or maybe it was a trawl, she did indeed mention that she was "bumming off an unsecured Wifi access point" a leetle bit too early in the thread...
Without public key verification (either by certificate, or by manually comparing fingerprints) there can be no security against such attacks.
What about simply creating a better web of trust?
Congratulations!
You Sir have just re-invented CaCert. CaCert is a certification authority which operates by a web-of-trust model: users certify each other after seeing id, and only users having gathered a minimum amount of assurance points can get a certificate.
Unfortunately, CaCert is not trusted by the browsers (such as Mozilla or Konqueror), who seem to be more hung up about expensive audits and pompous root key signing ceremonies.
Other CA's, such as Comodo/CertStar or RapidSSL/GeoTrust don't seem to have any problems being blessed by browsers though. Thanks to these fly-by-nighters it's still very easy to mount an Mitm attack using your open Wifi honeypot, which will be undetectable, unlike this poser here.
The result:
We once had a case where a server had a certificate with 3 problems at once: expired, self-signed and mismatched hostname. Browsers pointed out all 3 problems together.
But frankly I don't know how I would verify it.
Well, it should barf on any site signed by RapidSSL, even legitimate ones. Does anybody have an example of a site signed by RapidSSL?
Another way to test it would be would to set up your own CA using openssl, import it into your browser, then create an MD5-signed sub CA certificate for it, and finally use the sub CA to make a certificate for your website. But does anybody know how to convince openssl to use MD5 rather than SHA-1 for signing certificates?
You'd of course have to set the clock on your machine back to the time where the certificate was valid if you wanted to see the proof of concept.
Many browsers display the reason(s) why a certificate is rejected. So, in this case, it would say "Expired certificate and invalid CA in chain of trust"
After reading this article, I think that RapidSSL/FreeSSL should stop issuing certificates altogether.
Indeed. This MD5 issue is not the only problem that RapidSSL has. Their biggest issue is that they don't do any effort whatsoever to verify the requestor's identity. All the requestor has to do is:
The phone number is not verified, and using the number of a pre-paid mobile plan (or a callable phone booth) will work just fine.
Two may be a little bit tougher, until you think against what a certificate is supposed to protect: man-in-the-middle attacks.
So if the perp can get close enough to his target to mount a man-in-the-middle attack, he can also intercept mails sent to that target. Or, if the target is a webmail provider (hotmail, ...), he only needs to create one account out of the many allowed on the service.
Contrast this with other certification authorities, such as CA-Cert, which require a face-to-face verification with at least two volunteers which are trained and can be held responsible for errors.
Granted, domain ownership verification is not any more stringent than with RapidSSL (except for a smaller list of possible admin adresses), but at least in case of fraud, CaCert will have a chain of assurers leading to the perp in case of fraud, whereas RapidSSL would only have the number of a phone booth in a shady neighborhood.
Now, guess who is trusted by most browsers?
Yes, RapidSSL is, while CaCert isn't.
We prefer these orbits because they best serve the equatorial regions we have monopolized.
I know I should be feeding a troll, but the reason for putting most communications' satellites into equatorial orbits is that these are the only orbits that can be geostationary (satellite stays put relatively to the surface).
You really prefer to be able to leave your antenna's pointed to the same spot in the sky, rather than having to equip it with a motor that follows the satellite around.
If I received papers via Facebook I'd just ignore them, as there is not way anyone else could know whether I received them, or that the account was actually me.
But what if the lawyers posted the papers to your wall, rather than your inbox? In that case, all your "friends" would know too, and if you weren't careful with whom you befriended on facebook, some might rat you out (confirming that (1) it was indeed you, and (2) that you logged on, which they know because you accepted that nice christmas ornament they sent you).
But I've got the impression that they do it for exactly the opposite reason: because such replies do not create a legal liability.
As you can imagine, the chances of you disappearing from society and leaving no trace of how to contact you with employers, neighbors, family, and friends is fairly small...unless you're running from something.
I know a guy who thought it smart to just "disappear" for a year, touring the world.
When he came back, his large real estate holdings were foreclosed, because there was problems with some tenants who failed to pay their utility bills and just left (some even taking the keys with them...). The company that my friend had hired to look after the building failed to do anything about the situation, so the city moved to confiscate the building in order to pay the bills.
"Fortunately" California's prop 8 guarantees that you can't have an even worse situation, i.e. one where only the social security number would be different...
Running Windows Usenet clients in Wine is one solution, but I'd really like a FOSS solution.
That must be the lamest troll I've seen in ages...
Anybody got any suggestions? I'm an old fart and won't give up my Usenet until they pry it from my cold, dead fingers.
Do you also go to the nearest Democratic convention if you want to get a gun? Do you got to a disco if you want to listen to classical music?
Now, after 64-bit flash, and 64-bit java, we now only miss a 64 bit Luxtrust libgemsafe module... So, Luxtrust, when are you going to move?
Teachers have to have the right to confiscate property.
They may have the right to confiscate property, but they don't have the right to slander people.
If you do think that slander is ok, I'd suggest that the kid asks for a private meeting with the teacher about this whole Linux CD issue.
After the meeting, the kid can then run around and claim that much more interesting things happened during that meeting than actually happened. Should be fun.
A wire transfer typically costs $25 outgoing and $12 incoming
Even Fortis isn't that expensive... Try more something more like â3. And you have the appropriate plan ("Global Club"), you get a number of free wire transfers per quarter.
and you need to know the receiver's bank account # & routing number.
Which surprise most people do. Bank routing numbers (BIC) are published by the banks themselves, and account numbers of people wanting to receive such transfers (shops, charities, admistrations ...) are public too. And if it's family or friends, they can give you their account number easily. Oh, and usually the account number is only enough if you want to put money on an account. If you want to remove money from an account, you'll need something more, such as a password, a signature plus id, etc.
I seriously doubt that it is used that much by most people.
Well, here in Europe, it is used very commonly, for all kinds of things.
Cute boy...
The only possibility I see is a machine used for sustaining life (obviously for the user of the gun, not the recipient of the bullet).
"Investigation, replacement, modification, or support of the anatomy or a physiological process" also looks about right to me. Nowhere did it say that the process (life) needed to be modified for the better, and ending a process certainly looks like one kind of modification to me.