On the other hand, such powerful lasers are hard to make and very expensive. It would be tempting to make them just barely strong enough to work against existing designs which have no defense against such countermeasures. If a spinning (or randomly tumbling), mirrored shell, can cut down the rate of heating by something like 30%, and there's some extra heat-shielding inside, it might be enough to survive.
A few points:
Artillery shells and ballistic missiles already spin for stability.
Tumbling decreases accuracy by large margins.
There's only so much thermal shielding you can put in a projectile-- and the impetus for the projectile is to maximize the payload.
I think this is all very hypocritical. Marc Andreeson said just before win 95 came out that he didn't want to put Netscape Navigator on the shelf at the store, he wanted to have it bundled with the OS and distributed by the OEM's. He knew that would help solidify his market share. Then when MS did this same thing he cried foul. So why was it the right thing for him but the wrong thing for them?
Because MS is a monopoly in desktop OSes, and when you're a monopoly the rules are different. This is the essence of the Sherman Anti-Trust Act. It was and is foul for MS to bundle products.
> The hotmail trick is somewhat more insidious
> because it is used in the midst of a session the
> firewall will usually pass the traffic to a normally
> protected (even NAT'd) host.
... which couldn't have been reached without sending that first SYN, so you might as well traceroute it with the SYN in the first place.
I fail to see the significance of the difference.
Re:Paranoid? Or are they really out to get us?
on
Museum Of Broken Packets
·
· Score: 3, Informative
Worse-- the study looked only for three common stegongraphic tools, and noted that the best of them (OutGuess) has a new version that is not detectible using the method descibed in the study.
If you're smart enough to use steganography, wouldn't you be smart enough to use the latest version of the most advanced tool?
"Well, duh," again.
While I applaud Mr. Provos and Mr. Honeyman's efforts, the study uses a flawed methodology and this is reflected in the distinct lack of any real conclusions. You'll note that section 9, Conclusions doesn't actually conclude anything-- they simply state "we are unable to report finding a single message."
Yes, people bring younger and younger children to violent films these days, but this really had nothing to do with Mononoke's failure in the American market. American audiences like their movies simple, to the point of one-dimensionality. Look, for instance, at Titanic, which the average viewer will still tell you was a top-notch film: ol' Cal didn't have a redeeming bone in his body; and if DiCaprio could've been a more archetypical ragamuffin/loveable rogue, I'd have to vomit.
Real people aren't like that. Mononoke's complex characterizations are, frankly, beyond the ability of the average American movie-goer to grasp. It's unfortunate, but true.
That sealed Mononoke's fate. Put simply, there was no-one to hate. Since Eboshi didn't come with a big sign saying "Villain; Hate this Person," most American viewers couldn't find an interest.
Do I sound cynical?
Time-Warner/AOL refunded without prompting.
on
Code Red Refunds?
·
· Score: 1
My last bill for RoadRunner service was approximately half it's normal amount. The reduction was the result of a credit for intermittant loss of service for about two weeks. My city seemed to be particularly hard-hit by local CR/CRII infections (I was seeing about 20 arps/second at one point, just from my local segment-- not counting forwarded stuff).
Never asked. Now, I'm the last person to be a fan of mega-mega-octupii like TW/AOL, but I was impressed. Having worked for ISPs in the past I know that outage refunds are not unusual, but in my experience you ALWAYS have to ask.
It is exactly so in government shops. Budgets are scaled based on spending history-- the more you spend, the more you get. The more you get, the more people you hire. The more people you manage, the faster you advance ("We can't have a GS-14 managing over 100 people-- I'll sign your promotion...").
And people wonder why goverment agencies can't manage money.
The only problem with utilizing a non-MS KDC is that you can't use those tickets to access most Win2K-based services. Win2K services require the authorization data in the service ticket, which is essentially composed of group UIDs taken from AD. The Heimdal or MIT Kerberos KDC can't access or generate this data.
It is possible to do cross-realm authentication between an MS realm and a non-MS realm, but then you need to perform an account mapping so that the MS realm issues the proper service tickets at the end of the referral chain. Happy happy, joy joy.
At Hickam AFB near Honolulu, HI, the spalling caused by strafing runs during the attack has been preserved on a number of buildings still standing on the base.
It's an eerie feeling going to work in a building covered by pockmarks, and remembering exactly what that meant. Even more disturbing is noting that more than a dozen men died in the room in which I worked.
We fully support data, directory and system interop with UNIX, Linux, Novell, Mac, IBM mainframes through our base OS protocol support as well as through products like Services for UNIX, Interix, Services for NetWare, MetaDirectory and Host Integration Server.
This is pure crap and everyone knows it. If this is the case, why is it I can't have my MIT Kerberos realm issue tickets to access Win2K domain services *directly*? Or perhaps I really would prefer to use my Novell Directory Service instead of Win2K's Active Directory... No can do. Or perhaps I'd like to replace the Microsoft CA *required* for AD SMTP replication signing and DC-to-DC SSL with my own CA based on Netscape Certificate Authorities-- I can't.
Microsoft gives *interoperation* without *interoperability*. Modern, flexible systems are constructed out of modular components with defined standard interfaces. This allows the replacement of any component with any other component offering the same interface-- but this is *impossible* with Microsoft systems.
Mr. Miller's comments are the same lip service we always get. Sounds good to the press but doesn't have the technical meat to back it up. Mr. Miller should definitely know better, and probably does.
The essential role of government is to protect the rights of its citizens; this is the libertarian ideal. Historically, this has meant protecting against encroachments by foreign nations, other citizens, and the government itself.
To this, I would add a fourth role: protecting the citizenry against encroachments by private corporations.
This throws the libertarian ideal into a quandry. How does one protect the citizenry from the growing power of the corporation whilst preserving the freedom of the corporation to operate? Currently, only regulation gives the government any power in this fourth regard, but regulation is antithetical to libertarian ideaology.
I've thought long on this. There are some ways to mitigate the threat-- liability law with teeth, for instance; doing away with limited liability; nullification of anticompetition clauses and nondisclosure contracts-- but even together the problem remains.
Re:SOAP potentially a security problem.
on
Perl and .NET
·
· Score: 1
Security is a process with many layers. Boundary protection isn't the end-all, be-all-- but it can't be ignored either. It is and will remain a *part* of secure systems for the forseeable future.
SOAP potentially a security problem.
on
Perl and .NET
·
· Score: 1
Consider-- a distributed application invoking methods on objects using HTTP as the transport. It's going to be difficult to near-impossible to properly eliminate this stuff at the network perimeter.
At least existing RPC protocols utilize unique transports I can allow or deny easily.
Exchange prefers MAPI for serving mail. MAPI is an RPC protocol, so it hits a low port and migrates to a high port, usually random. Unless you know what you're doing, the high port is random. Firewalls don't cope well with things like that.
If you do know what you're doing, the high port can be locked down to a single port. But then you've put an cap on the number of sessions the server can handle. So now you need a high port *range*, which also sucks from a network perimeter protection point of view.
Exchange calendars, global address list, and public folders *only* work over RPC protocols, which suffer the same problems as MAPI. All these RPC protocols are cleartext, or trivially obfuscated, so are subject to all the passive attacks you can conceive.
So if the boss wants email from home, he's either got to have a VPN, with all the risks that involves (i.e., hijack the exposed remote client and ride the tunnel inside), or he's got to give up some of Exchange's features.
Exchange can do IMAP, and even IMAP/SSL-- but if you're going to do that, why bother with Exchange at all? If you're reading Exchange over IMAP, you lose the calendar, GAL, and public folders. Outlook can handle LDAP (and LDAP/SSL) directories and Exchange can provide the GAL over LDAP, but you *will* lose the calendar any time you use any kind of securable protocol.
Of course, if you decide to go with Exchange providing IMAP/SSL and LDAP/SSL, why bother with Exchange at all? Both are easily served by other means, with better security-- for instance, Exchange does IMAP/SSL, but will *not* do a client certificate check (nor will Outlook respond to one). So if your organization is deploying any kind of PKI, you can't take advantage of it. iPlanet Messaging Server, Critical Path's IMAP server, and Netscape Messanger, on the other hand, do both. And they support SSL authentication (a.k.a. X.509 certificate authentication a.k.a. PKI authentication)-- no passwords!
There's always Outlook Web Access for remote email, but OWA (or any web-based email system) cannot deal with encrypted messaging, so S/MIME is right out, should you have any plans in that regard. Further, OWA runs only on IIS, and *must* have extensive domain rights (to get at all those mail stores). Feel free to read the log of IIS holes big enough to fly a starship through on your own for why this is a Bad Idea(tm).
Further, any Exchange system has a built-in inefficiency. Each and every message that transits the system must be converted from RFC822 format to "Exchange format", and possibly back again (such as when serving it over IMAP). Other systems, particularly UNIX based systems, do not; the message remains in RFC822 format. This has implications for sizing large mail sites appropriately, particularly with high-volume mailing lists.
Speaking of mailing lists, if you want to establish an Exchange list with members *not* in your Exchange domain you must add them as custom contacts, which rapidly gets to be a bear to administrate. Many sites I know run Exchange for SMTP mail and a parallel UNIX server to handle mailing lists for this reason alone.
But is always comes down to that damn calendar. It's the groupware functions that seem to drive the Exchange migrations I've seen. Find them another way that will make them happy, and you might get to keep a more capable and flexible back end. I recommend a good web-based calendar (iPlanet's new version looks good, if they managed to release it, though it still needs the SSL and SSL authentication support) and shared workspace (a la BSCW).
But selling it when you're up against all those MCS guys with the fat expense accounts is always a problem.
I read through the white paper linked to from the main FUD page. In it, they claim that NT has a 37% lower TCO. However, buried within was this little marvel:
However, Sun environments have typically been in place longer and have had enterprise capabilities for several years. As a result, although the average number of users is almost the same (925 vs 990) Sun systems in certain cases run in more demanding environments:
The average database size on Sun systems is 47% larger than on Microsoft/Compaq systems. More Sun users (39%) than Microsoft users (25%) are running transactional applications on their servers. More Sun users (55%) than Microsoft users (46%) are running Web applications on their systems; Sun systems have a higher average number of concurrent sessions (160 vs. 98) and hits per day (3,462 vs. 1,423).
So, in short, your cost is 37% lower, but your capability is reduced roughly by 50%. One wonders exactly how this is a win for MS...
The whole issue of whether or not the NSA has a backdoor into CryptoAPI is moot, frankly. What's being missed here is that the system allows *arbitrary replacement* of the backup key, which would allow *any arbitrary CSP* to be installed on for system use *without user intervention or knowledge*.
How long before we see a trojaned CAPI with an installer that replaces the backup key? While there is potential for abuse by law enforcement, there is also *significant* risk of key compromise by third parties as well.
Attempts at protecting digital recordings are doomed to failure. In the case of music, there's nothing that can stop me from putting a vampire tap on the damn stereo cables and recording the unencrypted data stream. Similar objections apply to video data.
As far as watermarking the data files go, since the signal is analog (as it comes out my speakers), I can invalidate any watermarking that's encoded in the signal from the digital data file by the simple expedient of rerecording at a different sample rate than the original.
That's only one of three methods. The second takes advantage of a known protocol idiosyncracy of Linux.
The third method takes response time data from hosts before and during a flood of packets with bogus MAC addresses. This is the core detection routine, and actually comprises three different timing attacks.
There are multiple techniques to invalidate these tests; however, the intent of the tool is to detect *unauthorized* sniffing on a segment, and a number of the best anti-antisniffer techniques imply control of the surrounding network infrastructure...
It's an arms race, but isn't it always? The tool has its place.
Of all tyrannies, a tyranny exercised for the good of its victims may be the most oppressive. It may be better to live under robber barons than under omnipotent moral busybodies. The robber baron's cruelty may sometimes sleep, his cupidity may at some point be satiated; but those who torment us for our own good will torment us without end, for they do so with the approval of their consciences. -- C. S. Lewis
They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -- Benjamin Franklin
We live in a nation where our essential liberties-- those guaranteed us by the foundation documents of our government-- have come under constant attack: free and peacable assembly, free speech, illegal search and seizure, and free exercise of religion, to name but a few.
Our nation was founded with the overriding guiding precept of Liberty. Somewhere along the way we have lost that ideal, and replaced it by making Democracy alone our watchword-- a poor substitute, for Democracy in and of itself places no limits upon the enaction of a popular tyranny.
The *point* of the GPL (which the kernel is under) is that modifications *have* to be available source-form for no more than a copying fee for the media.
So if Sony embeds Linux in the PSX2, they *have* to make it available. And it won't take long for the community to find out what it's running inside once it ships.
Slashdot Mirror
Of course, that would make the launch emplacement glaringly obvious in the recon photos...
On the other hand, such powerful lasers are hard to make and very expensive. It would be tempting to make them just barely strong enough to work against existing designs which have no defense against such countermeasures. If a spinning (or randomly tumbling), mirrored shell, can cut down the rate of heating by something like 30%, and there's some extra heat-shielding inside, it might be enough to survive.
A few points:
I think this is all very hypocritical. Marc Andreeson said just before win 95 came out that he didn't want to put Netscape Navigator on the shelf at the store, he wanted to have it bundled with the OS and distributed by the OEM's. He knew that would help solidify his market share. Then when MS did this same thing he cried foul. So why was it the right thing for him but the wrong thing for them?
Because MS is a monopoly in desktop OSes, and when you're a monopoly the rules are different. This is the essence of the Sherman Anti-Trust Act. It was and is foul for MS to bundle products.
> The hotmail trick is somewhat more insidious
> because it is used in the midst of a session the
> firewall will usually pass the traffic to a normally
> protected (even NAT'd) host.
... which couldn't have been reached without sending that first SYN, so you might as well traceroute it with the SYN in the first place.
I fail to see the significance of the difference.
Y'all DO know about tcptraceroute, right?
Worse-- the study looked only for three common stegongraphic tools, and noted that the best of them (OutGuess) has a new version that is not detectible using the method descibed in the study.
If you're smart enough to use steganography, wouldn't you be smart enough to use the latest version of the most advanced tool?
"Well, duh," again.
While I applaud Mr. Provos and Mr. Honeyman's efforts, the study uses a flawed methodology and this is reflected in the distinct lack of any real conclusions. You'll note that section 9, Conclusions doesn't actually conclude anything-- they simply state "we are unable to report finding a single message."
Yes, people bring younger and younger children to violent films these days, but this really had nothing to do with Mononoke's failure in the American market. American audiences like their movies simple, to the point of one-dimensionality. Look, for instance, at Titanic, which the average viewer will still tell you was a top-notch film: ol' Cal didn't have a redeeming bone in his body; and if DiCaprio could've been a more archetypical ragamuffin/loveable rogue, I'd have to vomit.
Real people aren't like that. Mononoke's complex characterizations are, frankly, beyond the ability of the average American movie-goer to grasp. It's unfortunate, but true.
That sealed Mononoke's fate. Put simply, there was no-one to hate. Since Eboshi didn't come with a big sign saying "Villain; Hate this Person," most American viewers couldn't find an interest.
Do I sound cynical?
My last bill for RoadRunner service was approximately half it's normal amount. The reduction was the result of a credit for intermittant loss of service for about two weeks. My city seemed to be particularly hard-hit by local CR/CRII infections (I was seeing about 20 arps/second at one point, just from my local segment-- not counting forwarded stuff).
Never asked. Now, I'm the last person to be a fan of mega-mega-octupii like TW/AOL, but I was impressed. Having worked for ISPs in the past I know that outage refunds are not unusual, but in my experience you ALWAYS have to ask.
It is exactly so in government shops. Budgets are scaled based on spending history-- the more you spend, the more you get. The more you get, the more people you hire. The more people you manage, the faster you advance ("We can't have a GS-14 managing over 100 people-- I'll sign your promotion...").
And people wonder why goverment agencies can't manage money.
The only problem with utilizing a non-MS KDC is that you can't use those tickets to access most Win2K-based services. Win2K services require the authorization data in the service ticket, which is essentially composed of group UIDs taken from AD. The Heimdal or MIT Kerberos KDC can't access or generate this data.
It is possible to do cross-realm authentication between an MS realm and a non-MS realm, but then you need to perform an account mapping so that the MS realm issues the proper service tickets at the end of the referral chain. Happy happy, joy joy.
At Hickam AFB near Honolulu, HI, the spalling caused by strafing runs during the attack has been preserved on a number of buildings still standing on the base.
It's an eerie feeling going to work in a building covered by pockmarks, and remembering exactly what that meant. Even more disturbing is noting that more than a dozen men died in the room in which I worked.
This is pure crap and everyone knows it. If this is the case, why is it I can't have my MIT Kerberos realm issue tickets to access Win2K domain services *directly*? Or perhaps I really would prefer to use my Novell Directory Service instead of Win2K's Active Directory... No can do. Or perhaps I'd like to replace the Microsoft CA *required* for AD SMTP replication signing and DC-to-DC SSL with my own CA based on Netscape Certificate Authorities-- I can't.
Microsoft gives *interoperation* without *interoperability*. Modern, flexible systems are constructed out of modular components with defined standard interfaces. This allows the replacement of any component with any other component offering the same interface-- but this is *impossible* with Microsoft systems.
Mr. Miller's comments are the same lip service we always get. Sounds good to the press but doesn't have the technical meat to back it up. Mr. Miller should definitely know better, and probably does.
Netscape Messenger.
The essential role of government is to protect the rights of its citizens; this is the libertarian ideal. Historically, this has meant protecting against encroachments by foreign nations, other citizens, and the government itself.
To this, I would add a fourth role: protecting the citizenry against encroachments by private corporations.
This throws the libertarian ideal into a quandry. How does one protect the citizenry from the growing power of the corporation whilst preserving the freedom of the corporation to operate? Currently, only regulation gives the government any power in this fourth regard, but regulation is antithetical to libertarian ideaology.
I've thought long on this. There are some ways to mitigate the threat-- liability law with teeth, for instance; doing away with limited liability; nullification of anticompetition clauses and nondisclosure contracts-- but even together the problem remains.
Security is a process with many layers. Boundary protection isn't the end-all, be-all-- but it can't be ignored either. It is and will remain a *part* of secure systems for the forseeable future.
Consider-- a distributed application invoking methods on objects using HTTP as the transport. It's going to be difficult to near-impossible to properly eliminate this stuff at the network perimeter.
At least existing RPC protocols utilize unique transports I can allow or deny easily.
Exchange prefers MAPI for serving mail. MAPI is an RPC protocol, so it hits a low port and migrates to a high port, usually random. Unless you know what you're doing, the high port is random. Firewalls don't cope well with things like that.
If you do know what you're doing, the high port can be locked down to a single port. But then you've put an cap on the number of sessions the server can handle. So now you need a high port *range*, which also sucks from a network perimeter protection point of view.
Exchange calendars, global address list, and public folders *only* work over RPC protocols, which suffer the same problems as MAPI. All these RPC protocols are cleartext, or trivially obfuscated, so are subject to all the passive attacks you can conceive.
So if the boss wants email from home, he's either got to have a VPN, with all the risks that involves (i.e., hijack the exposed remote client and ride the tunnel inside), or he's got to give up some of Exchange's features.
Exchange can do IMAP, and even IMAP/SSL-- but if you're going to do that, why bother with Exchange at all? If you're reading Exchange over IMAP, you lose the calendar, GAL, and public folders. Outlook can handle LDAP (and LDAP/SSL) directories and Exchange can provide the GAL over LDAP, but you *will* lose the calendar any time you use any kind of securable protocol.
Of course, if you decide to go with Exchange providing IMAP/SSL and LDAP/SSL, why bother with Exchange at all? Both are easily served by other means, with better security-- for instance, Exchange does IMAP/SSL, but will *not* do a client certificate check (nor will Outlook respond to one). So if your organization is deploying any kind of PKI, you can't take advantage of it. iPlanet Messaging Server, Critical Path's IMAP server, and Netscape Messanger, on the other hand, do both. And they support SSL authentication (a.k.a. X.509 certificate authentication a.k.a. PKI authentication)-- no passwords!
There's always Outlook Web Access for remote email, but OWA (or any web-based email system) cannot deal with encrypted messaging, so S/MIME is right out, should you have any plans in that regard. Further, OWA runs only on IIS, and *must* have extensive domain rights (to get at all those mail stores). Feel free to read the log of IIS holes big enough to fly a starship through on your own for why this is a Bad Idea(tm).
Further, any Exchange system has a built-in inefficiency. Each and every message that transits the system must be converted from RFC822 format to "Exchange format", and possibly back again (such as when serving it over IMAP). Other systems, particularly UNIX based systems, do not; the message remains in RFC822 format. This has implications for sizing large mail sites appropriately, particularly with high-volume mailing lists.
Speaking of mailing lists, if you want to establish an Exchange list with members *not* in your Exchange domain you must add them as custom contacts, which rapidly gets to be a bear to administrate. Many sites I know run Exchange for SMTP mail and a parallel UNIX server to handle mailing lists for this reason alone.
But is always comes down to that damn calendar. It's the groupware functions that seem to drive the Exchange migrations I've seen. Find them another way that will make them happy, and you might get to keep a more capable and flexible back end. I recommend a good web-based calendar (iPlanet's new version looks good, if they managed to release it, though it still needs the SSL and SSL authentication support) and shared workspace (a la BSCW).
But selling it when you're up against all those MCS guys with the fat expense accounts is always a problem.
-- Cerebus
I read through the white paper linked to from the main FUD page. In it, they claim that NT has a 37% lower TCO. However, buried within was this little marvel:
So, in short, your cost is 37% lower, but your capability is reduced roughly by 50%. One wonders exactly how this is a win for MS...
The whole issue of whether or not the NSA has a backdoor into CryptoAPI is moot, frankly. What's being missed here is that the system allows *arbitrary replacement* of the backup key, which would allow *any arbitrary CSP* to be installed on for system use *without user intervention or knowledge*.
How long before we see a trojaned CAPI with an installer that replaces the backup key? While there is potential for abuse by law enforcement, there is also *significant* risk of key compromise by third parties as well.
Where would you like your keys to go today?
Attempts at protecting digital recordings are doomed to failure. In the case of music, there's nothing that can stop me from putting a vampire tap on the damn stereo cables and recording the unencrypted data stream. Similar objections apply to video data.
As far as watermarking the data files go, since the signal is analog (as it comes out my speakers), I can invalidate any watermarking that's encoded in the signal from the digital data file by the simple expedient of rerecording at a different sample rate than the original.
That's only one of three methods. The second takes advantage of a known protocol idiosyncracy of Linux.
The third method takes response time data from hosts before and during a flood of packets with bogus MAC addresses. This is the core detection routine, and actually comprises three different timing attacks.
There are multiple techniques to invalidate these tests; however, the intent of the tool is to detect *unauthorized* sniffing on a segment, and a number of the best anti-antisniffer techniques imply control of the surrounding network infrastructure...
It's an arms race, but isn't it always? The tool has its place.
-- Cerebus
Of all tyrannies, a tyranny exercised for the good of its victims may be the most oppressive. It may be better to live under robber barons than under omnipotent moral busybodies. The robber baron's cruelty may sometimes sleep, his cupidity may at some point be satiated; but those who torment us for our own good will torment us without end, for they do so with the approval of their consciences.
-- C. S. Lewis
They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.
-- Benjamin Franklin
We live in a nation where our essential liberties-- those guaranteed us by the foundation documents of our government-- have come under constant attack: free and peacable assembly, free speech, illegal search and seizure, and free exercise of religion, to name but a few.
Our nation was founded with the overriding guiding precept of Liberty. Somewhere along the way we have lost that ideal, and replaced it by making Democracy alone our watchword-- a poor substitute, for Democracy in and of itself places no limits upon the enaction of a popular tyranny.
The Libertarian Party website is here.
The *point* of the GPL (which the kernel is under) is that modifications *have* to be available source-form for no more than a copying fee for the media.
So if Sony embeds Linux in the PSX2, they *have* to make it available. And it won't take long for the community to find out what it's running inside once it ships.
-- Cerebus
Now seems a good point to comment that OpenDoc is still out there, not-quite-yet-dead.
IIRC, IBM & Apple were going to OpenSource the APIs. But I may be wrong.
-- Cerebus
We *are* talking about the the same "programmer" who couldn't write a working flood-fill routine for MS Basic, aren't we?
Read _Barbarians Led by Bill Gates_. An eye-opener; I'm amazed they ever shipped a single product.
-- Cerebus