Internet is a harsh mistress. If you can't be thick-skinned, go find different way to spend your time. And posting on-line, to world at large, "look how miserable we are" is just whoring.
I have exactly the same problems in both virtual and physical environments, the speed is capped at around 600-700Mb/s.
And I am obviously using Citrix drivers, otherwise I'd be capped at 100Mbps. Or are you suggesting they can't write drivers that actually work for their primary product? I mean, they don't even release XenCenter (the management console for XenServer) for Linux!. They are very much Windows-centric.
As I said, Linux hosts can do 1Gbps on the same host -- gigabit networking doesn't require top-of-the-line Intel i7, I can do it with 1.6GHz C2D, 6 core Phenom II at 3.2GHz should be more than capable, even with visualization overhead.
I have exactly the same problem, even after extensive tunning I can't get over 600-700Mb/s between a linux server and Windows 7 in virtual environment, where there's no possibility of crappy hardware or drivers. Between Linux machines I can easily get 1Gbps up and down at the same time.
Windows 7 tcp stack is borked
The only thing that might prevent this, is hoping the revocation list of diginotar is complete
> implying browsers actually check CRL or OCSP responses
HA HA, good one. Only Opera checks OCSP and won't show you that the site is "secure" when it can't contact the OCSP server. Firefox can be defeated by putting "3" in the OCSP response (come on, we're talking about full scale MITM, adding OCSP to atack, which also uses HTTP is trivial). IE even when gets a OCSP failure or can't connect to OCSP at all will still show green bar...
If you're using regular certificates Firefox and IE don't even check for OCSP...
It's a good scheme as long as you can trust your registrar and your country government. For small business and private sites it's a solution good enough in a road to phase out unsecured HTTP. Not a solution if you want/need real security.
The current CA woes show that probably the CAs weren't attacked because the script-kiddies and "real crackers" thought of them as ivory towers, completely impenetrable.
In the coming months we can be fairly certain that more and more CAs will fall victim to attacks, just like Sony.
There are extensions to TLS that allow the server to provide the client the OCSP response that its certificate is valid. Considering that the regular OCSP response has a validity period of one to two days, even if CA OCSP server goes down, Amazon architecture stays up and remains secure. Second: CA can create multiple OCSP servers distributed over geographically diverse locations. They have the money to do that and creation of robust systems is possible: when was the last time you couldn't go to google.com while your Internet was up?
People keep forgetting that security is a process, not a service or magic pixie dust. You have to constantly update it. Yet still the there were absolutely no major changes between introduction of SSL and now, we still have CAs that provide CRL and OCSP service only on paper, browsers that don't bother checking it at all. The biggest change was phasing out of MD5 (while we shouldn't be using SHA1 now) and phasing out of SSL2 (still used by over 25% of SSL-enabled sites in the Internet).
The biggest problem is that the Joe Random doesn't even see the whole issue as a problem so the big players do absolutely nothing.
Microsoft still didn't implement their own open standards (ISO OOXML) and CIFS is still has parts closed so if they want software using open standards they shouldn't touch MS stuff with a 10 foot barge-pole.
From what I read about Singularity and Midori they are doing exactly the same fundamental mistake as with NT.
They assume drivers are secondary to OS code. In reality, over 50% of Linux code are drivers, current drivers, without legacy code. The main OS code (scheduler, signal passing, etc.) is less than 10%, bump it to 20% if you want to get architecture dependent code. Somehow I don't see writing drivers in C#, or any other manged language. MS themselves tell that well over half of bluescreens on Vista come from bugs in drivers, usually the graphical ones.
if only you could forsee that customers will want to use something other than Windows on a 1GHz Geode with 128MB RAM...
Seriously, Linux has huge market share in anything but desktops. If you make hardware you know that someone, somewhere will want to use it with Linux. Making the driver OSS from the start will save you tons of problems in the long run.
I manage over a dozen boxes with Ubuntu on them. The only hardware that ever caused me headaches are printers. Everything else Just Works.
And even printers are nowhere near as problematic as on the Windows side: I recently connected a new printer to one of those computers: Lexmark E260. The biggest (and only) problem was deleting the old printer and renaming the new one. Both easily done with GUI. The drivers were installed automatically.
OCSP requires client to provide hash of DN, hash of public key and serialNumber of certificate.
What's more. EJBCA (open source Enterprise Java Beans Certificate Authority software) requires you to keep all issued certificates in database otherwise OCSP responder won't work. Both allow, and even suggest that a whitelist can and even is used to check for revocation data.
Are you sure it's not implementation specific?
In fact, RFC2560 states:
For this service to be effective, certificate using systems must
connect to the certificate status service provider. In the event such
a connection cannot be obtained, certificate-using systems could
implement CRL processing logic as a fall-back position.
3. Can you be a bit more specific about what you proposed in 1993 ?
There is a Secure Remote Password protocol that allows you to authenticate both server to you and yourself to server at the same time. There's also a RFC 5054 aimed to incorporate it to TLS, unfortunately without any client support AFAIK.
OCSP requires you to remember all certs you issue, CRL requires you to remember all certs you revoked. To have proper support for both mechanisms (which most CAs do) you need to have full list of certificates, both currently valid and revoked.
It looks like the attackers acquired full control over software DigiNotar used to create its certificates. Once you have full control over the software you can create certificates that won't be included in the list of issued certificates (as used by OCSP).
Pair that with fact that most browsers (and practically all software using TLS) doesn't use OCSP. The result is something that is quite equal to a private key compromise - attackers could have created a rogue subCA that will be trusted by all browsers but Opera - and as long as we don't find the intermediate cert in some rogue server we won't even have a fingerprint to blacklist using either internal browser mechanisms or CRL.
Slashdot Mirror
Internet is a harsh mistress. If you can't be thick-skinned, go find different way to spend your time. And posting on-line, to world at large, "look how miserable we are" is just whoring.
I have exactly the same problems in both virtual and physical environments, the speed is capped at around 600-700Mb/s.
And I am obviously using Citrix drivers, otherwise I'd be capped at 100Mbps. Or are you suggesting they can't write drivers that actually work for their primary product? I mean, they don't even release XenCenter (the management console for XenServer) for Linux!. They are very much Windows-centric.
As I said, Linux hosts can do 1Gbps on the same host -- gigabit networking doesn't require top-of-the-line Intel i7, I can do it with 1.6GHz C2D, 6 core Phenom II at 3.2GHz should be more than capable, even with visualization overhead.
mod parent up!
I have exactly the same problem, even after extensive tunning I can't get over 600-700Mb/s between a linux server and Windows 7 in virtual environment, where there's no possibility of crappy hardware or drivers. Between Linux machines I can easily get 1Gbps up and down at the same time.
Windows 7 tcp stack is borked
XP is filled with security holes
And that's different from any other Windows system in what way?
apt-get install aptitude
the day Ubuntu removes apt system is the day Ubuntu dies
The only thing that might prevent this, is hoping the revocation list of diginotar is complete
> implying browsers actually check CRL or OCSP responses
HA HA, good one. Only Opera checks OCSP and won't show you that the site is "secure" when it can't contact the OCSP server. Firefox can be defeated by putting "3" in the OCSP response (come on, we're talking about full scale MITM, adding OCSP to atack, which also uses HTTP is trivial). IE even when gets a OCSP failure or can't connect to OCSP at all will still show green bar...
If you're using regular certificates Firefox and IE don't even check for OCSP...
It's a good scheme as long as you can trust your registrar and your country government. For small business and private sites it's a solution good enough in a road to phase out unsecured HTTP. Not a solution if you want/need real security.
The current CA woes show that probably the CAs weren't attacked because the script-kiddies and "real crackers" thought of them as ivory towers, completely impenetrable.
In the coming months we can be fairly certain that more and more CAs will fall victim to attacks, just like Sony.
There are extensions to TLS that allow the server to provide the client the OCSP response that its certificate is valid. Considering that the regular OCSP response has a validity period of one to two days, even if CA OCSP server goes down, Amazon architecture stays up and remains secure. Second: CA can create multiple OCSP servers distributed over geographically diverse locations. They have the money to do that and creation of robust systems is possible: when was the last time you couldn't go to google.com while your Internet was up?
People keep forgetting that security is a process, not a service or magic pixie dust. You have to constantly update it. Yet still the there were absolutely no major changes between introduction of SSL and now, we still have CAs that provide CRL and OCSP service only on paper, browsers that don't bother checking it at all. The biggest change was phasing out of MD5 (while we shouldn't be using SHA1 now) and phasing out of SSL2 (still used by over 25% of SSL-enabled sites in the Internet).
The biggest problem is that the Joe Random doesn't even see the whole issue as a problem so the big players do absolutely nothing.
No one is running their servers on a single HDD, let alone SSDs which are unproven technology.
If you use single drive, it fails and you loose data you're the only one to blame.
Disc recovery is not an option is business environment, you have to have backups.
Microsoft still didn't implement their own open standards (ISO OOXML) and CIFS is still has parts closed so if they want software using open standards they shouldn't touch MS stuff with a 10 foot barge-pole.
also known as the "No one has been fired for buying IBM" solution
From what I read about Singularity and Midori they are doing exactly the same fundamental mistake as with NT.
They assume drivers are secondary to OS code. In reality, over 50% of Linux code are drivers, current drivers, without legacy code. The main OS code (scheduler, signal passing, etc.) is less than 10%, bump it to 20% if you want to get architecture dependent code. Somehow I don't see writing drivers in C#, or any other manged language. MS themselves tell that well over half of bluescreens on Vista come from bugs in drivers, usually the graphical ones.
if only you could forsee that customers will want to use something other than Windows on a 1GHz Geode with 128MB RAM...
Seriously, Linux has huge market share in anything but desktops. If you make hardware you know that someone, somewhere will want to use it with Linux. Making the driver OSS from the start will save you tons of problems in the long run.
Imagine how many billions of man-hours could have been saved over the past 15 years if IE didn't exist in the first place...
Try FLAC audio.
I manage over a dozen boxes with Ubuntu on them. The only hardware that ever caused me headaches are printers. Everything else Just Works.
And even printers are nowhere near as problematic as on the Windows side: I recently connected a new printer to one of those computers: Lexmark E260. The biggest (and only) problem was deleting the old printer and renaming the new one. Both easily done with GUI. The drivers were installed automatically.
It looks like he changed for the better.
Because installing AdBlockPlus on library computers is so realistic...
What's more. EJBCA (open source Enterprise Java Beans Certificate Authority software) requires you to keep all issued certificates in database otherwise OCSP responder won't work. Both allow, and even suggest that a whitelist can and even is used to check for revocation data.
Are you sure it's not implementation specific?
In fact, RFC2560 states:
For this service to be effective, certificate using systems must connect to the certificate status service provider. In the event such a connection cannot be obtained, certificate-using systems could implement CRL processing logic as a fall-back position.
Internet is not considered a strategic asset.
Quite ironic for a network that was designed to survive nuclear country-wide attack on US...
Mod parent up. I think it's the best way to show computing to children.
3. Can you be a bit more specific about what you proposed in 1993 ?
There is a Secure Remote Password protocol that allows you to authenticate both server to you and yourself to server at the same time. There's also a RFC 5054 aimed to incorporate it to TLS, unfortunately without any client support AFAIK.
OCSP requires you to remember all certs you issue, CRL requires you to remember all certs you revoked. To have proper support for both mechanisms (which most CAs do) you need to have full list of certificates, both currently valid and revoked.
It looks like the attackers acquired full control over software DigiNotar used to create its certificates. Once you have full control over the software you can create certificates that won't be included in the list of issued certificates (as used by OCSP).
Pair that with fact that most browsers (and practically all software using TLS) doesn't use OCSP. The result is something that is quite equal to a private key compromise - attackers could have created a rogue subCA that will be trusted by all browsers but Opera - and as long as we don't find the intermediate cert in some rogue server we won't even have a fingerprint to blacklist using either internal browser mechanisms or CRL.
Use for its softer touch in Internet trolling, for the care, he deserves.