People talking about Internet Time are usually talking about the fast-release cycles of software via the internet. The classic case was Netscape back in the early days.
Ahh so what was called Internet time was no more than the phenomena of companies releasing what used to be called Alpha release software to the public?
Great - wavelets are back again; however this time not for compression but for high-speed signaling and to avoid interference.
Reading the article I think that Cringely's biggest problem is that he does not understand how long it takes to get technology from a proof of concept to a working system.
With the Web it has taken ten years and counting to get this far. Idiot pumpers like Meaker and Blodget aside, Internet time runs at 1 for one with GMT at best.
I first heard about ISDN in the 80's, ten years later people started to get ISDN phone lines. Likewise with DSL the basic ideas were floating arround in the early 90s but are still not fully baked for deployment.
It does not seem unreasonable that people will be rolling out much faster cable networks in (say) 2010 or so. I don't think it is going to happen on any larg scale before then however. The DOCSIS standard has only just been developed and it will take at least 3 years for any radical redesign to make it into a spec and another 2 to get into production, then there will be the inevitable delay as results from trial deployments are assesed and so on.
What cringely and co miss is that athough the majority of the cost of a fully deployed system is at the consumer end s not where the killer costs lie. To roll out broadband access in a town you first have to buy lots of gear that typically comes with five or six figure price tags. You have to buy that gear whether one person buys service or ten thousand. The client end costs are not so much of a problem because each customer pays a subscription.
That is why the cable companies partnered with the losers @Home to deploy broadband. The cable cos were not prepared to gamble their capital on the success of broadband. @home was. Of course the minute that there was proof of the business plan @home became surplus to requirements
So yeah, wavelets, whatever, but at the moment the bandwidth in the last mile is not the bottleneck. Nor is the bottleneck in any of the pipes. There were four companies that deployed fibre backbones over the last five years, each of which has more capacity than the country could use before 2015. It is the switching capacity that is expensive and that comes down to pricey silicon and probably always will. If you have computing technology of power X you end up with switching nodes that require processing power of many, many X.
Don't overreact; the Judge had to rule on law, and that's what she did. It's not like once the cameras are barred MS will be able to do something sneaky; the state AGs are not as sympathetic to MS as the Ashcroft "Justice" Department is.
It does not appear very likely that the judge had any choice in the matter. Depositions are taken in private in all federal cases unless there is a specific requirement that they be public.
Once Microsoft protested the state AGs were bound to request the opposite regardless of what they would otherwise have requested since they could then grandstand with the openess claim.
Given that the state AGs are mostly political hacks and many come from states where a lot of voters work for companies that compete against Microsoft the scope for grandstanding in open depositions would have been huge. While the Federal government was running the case the state AGs had to take a back seat.
Ashcroft on the other hand is the type of political hack who loses an election to a dead man then spends $8000 of tax payers money having the statues in his HQ covered in a Burqua.
Not that RAID is a bad thing, but I have seen RAID systems go down
I once saw a shaddowing controller fail in such a way that it managed to corrupt both of the RAID 5 arrays it was driving.
Had to bring the system back up from the first level backup.
Since this device is cutting frames to make the program shorter, what will happen with the audio? How will they get the audio to sync up to the video if some of the video is missing. If they cut out 30 seconds of video from a program, then by the end of the show wouldn't the audio be 30 off?
Same way we used to do it in the cinema when you had a missing frame. If you stick a triangular piece of masking tape over the splice the audience never realises that it was there. The triangle causes the sound levels to be faded to zero and back again in an instant (well probably 1/100th sec).
The human ear can't detect that sort of thing because at the end of the day its actually doing a mechanical version of a fourier transform on the audio signal and drop-outs of that sort don't carry too well.
If you start doing the trick too often there is a significant chance that you miss soething important. Imagine listening to the 1812 overture with random pieces missing, so you don't hear the canon shot etc.
It is possible that they use some other sort of interpolation to smooth over the lost time but then you start to lose the sync between the actors lips and the sound track and it will start to look like Jackie Chan.
CPUs are so fast these days most people don't
even bother to turn on optimization. Not
worth the 2 seconds it takes to type "-O34".
A more likely reason for not turning on optimization would be not wanting to wait for the optimizer to run. Another good reason is that it is often harder to debug optimized code.
At one time though the most frequent reason to avoid the optimizer was that many were buggy as heck and would introduce all kinds of bugs based on an imperfect understanding of how the program work. This was particularly the so with Fortran compilers where the derranged semantics of the language often bit the optimizer hard. It would also bite the programers on many occasions who would make use of common blocks that was outlawed under the Geneva convention.
Intel has sold its compiler expertise for years. There is Intel code in most of the commercial compilers in use. I don't see why Intel should give code away to Microsoft to sell in Visual Studio.
Equally, there is little point in having an internal optimization team that can't beat an external team with no advance knowledge of the processor architecture.
With SOAP my program makes a function call, the CGI/SOAP backend generates a return value to be used by the program.
What you mean is that a SOAP client hooked up to (say) an XKMS trust service is subject to a greater degree of risk than a Web browser surfing Slashdot. Well Duuhhh!!!!
The protcol is irrelevant at that stage. The vulnerability comes from the fact that a large number of Web services are intended to support some pretty high trust applications. For example people are entirely serious about using Web services to move very large sums of money arround. XKMS is designed to be used to validate public keys used (amongst other things) to authorize very high value transactions.
But the people who are managing that type of application are quite aware of the risks involved. The risks are intrinsic to the application and the use of Web Services is incidental.
Nobody raised a fuss when we layered OCSP over HTTP - and that protocol was reviewed by pretty much the whole IETF security area.
Sendmail is a bad example, since, although a lot of people still use it despite it's flaws, there are other MTAs available and is not in itself a flaw in any version of Unix.
So follow the advice Bruce is giving to MSFT, ship the product safe by default. Take out sendmail which has been a festering sore and slot in something that deserves the default slot.
For many years the main contribution to the security world from the UNIX security architecture folk was discouraging people from using shaddow [sic]password files.
>I think you meant "encouraging people to use shadow password files".
No, until the first copies of crack started to circulate the issue would regularly start flamewars on the security lists. The original description of the UNIX password feature made a big deal of the fact that the password file was world readable. The argument Moriss used was that read protecting the password file was 'security through obscurity'.
Even after crack appeared it took quite a while for people to realise that the exhaustive search attack was becomming practical.
[sendmail discussion] Never is a long time. What box-breaching flaws are in the latest release? Oh, you were referring to those older releases still installed all over the place.
sendmail is insecure for the same reason that Outlook is insecure, the program provides an excessive and unnecessary degree of complexity. The vulnerability in sendmail is the complex macro rewrite rule engine. The vulnerability in Outlook is that it will execute active code in email.
The problem with both pieces of code is akin to radioactivity. No matter how long you wait there will always be some level of insecurity. The insecurity is there because the program does something that is a fundamentally bad idea.
Swapping out sendmail for one of the excellent alternatives is a much better solution than upgrading. Equally running the 'turn off active content' patch on outlook is a good plan.
when MS wanted to take advantadge of the Internet, they bullied their way in to the browser market.
They were invited. In fact the Web development team spent a lot of time and effort getting Microsoft to support the Web and deploy a browser.
Now they are going to bully their way into the security market, in orde to provide an integrated solution?
Microsoft already provide one of the most comprehensive cryptographic security packages out their. Windows 2000 implements most of the X.509/PKIX specification and the IPSEC, SMIME and SSL protocols, they also provide an encrypting file system
The problem with Microsoft is not that they fail to provide security features, it is that they also throw in some of the most amazingly braindamaged insecure ones.
For example, if Microsoft removed the scripting features from Outlook most of the Microsoft security issues would be eliminated at a stroke. If Microsoft eliminated scripting from Word, Excell etc the number of security issues would be cut in half again. The fondness of Redmond engineers for active code is their major security weakness.
It is a weakness that is not limited to Redmond either. Netscape's addition of Javascript to HTML was pretty gratuitous. I have yet to see any feature achieved with an active code platform perpetrated by Microsoft, Sun or Netscape that provides more benefit to the user than the programer.
The difference is subtle, with CGI programs attacks would affect the backend, deleting accounts, intercepting charge cards, outputting misinformation, etc.
The difference is far from subtle, the major difference between CGI and Web Services is that in the early days of CGI people would have cshell scripts processing the queries.
So in a short time people discovered that you could cause all sorts of programs to be run simply by sending a query of the form http://xx...xx?a=x;rm+-rf+* which would result in some script executing
greet x;rm -rf *
Give or take the correct URL escape hackery.
Rob and Ari discovered the joys of shared libraries pretty soon after their CGI hack. OK CGI is easier to get started in than the Apache or NSAPI plug in architecture, but it is a lot more secure. What do people use though?
The fact that there are still books arround with three inch spines and the letters CGI on the front cover selling by the hundreds in Frys tells me that there are plenty of folk using what was a one night hack by two undergrad students who have since mended their ways. Even so those same folk will go off and throw stones at Mr Softy.
Incidentaly I was in the next room when Ari wrote the CGI spec and I can assure you that the idea that there might be a security issue did not occur to him when he was writing it.
The difference is that at least on the client side is that if I hack a website with SOAP web services the results can now affect the software running locally. Thus manipulating software on the client side to do things they were not intended to do.
No, this is not the difference. In IIS the Web service runs as just another back-end service provider.
SOAP does make it easier to export a DLL library to the Web. So if an attacker got control of a machine with Visual Studio.NET they could cause the individual all sorts of grief by exporting their system DLLs as SOAP services, but there are already trojans that allow execution of arbitrary code and the firewall should not allow incomming HTTP requests on the internal net in any case. So yes SOAP provides an additional and somewhat more artistic way to torment a machine that has been captured, but it does not introduce a new way to torment a machine.
The ACL security moddle they ripped from VMS is great.
Try adding one to each letter in VMS...
The similarities between WNT and VMS are well known and hardly suprising since Dave Cutler was lead architect on both. I seem to recall ACLs are earlier, didn't Butler Lampson invent them in Multics or something?
Anyway the point Butler always makes when ACLs are discussed is that they are too granular. What you really want to be able to do is to associate a named security policy with the actual resources (files, devices, etc. etc.) and then have the ACL rules stored in the policy. This has two major effects, first it makes the system more manageable since you don't have to spend time propagating out all your ACL changes, secondly the O/S can cache the result of evaluating the ACL which saves a lot of time when doing things like directory copy operations.
VMS actually introduced a structure like this called a rights identifier, however it appeared after Cutler left so it may have been one of the features he always hated and had kept out as long as possible.
But it doesn't use SSL. httptunnel is not using the CONNECT proxy directive (which enables SSL connections through a proxy). It's using HTTP GET and HTTP POST, and that's it. To the proxy it looks like plain old HTTP. There's no SSL in it. SSHv1 yes, but not SSL. If you're unconvinced, thinking that ssh necessarily means that it's SSL, not a problem. It works with rsh, too.
You gave one example that is relatively easy to detect, I countered with a more powerful example that is impossible to detect.
The point that you apear to be determined to miss is that a firewall does not and cannot provide a meaningful control against the attack you describe. It does not do that today and it will not tommorow, whether SOAP runs over port 80 or no.
Again, the problem with firewalls is that they are considered by the naive to be a solution to every security solution ever. Like all security tools they have a very specific and narrow use.
The attack that I describe does require that the sender and receiver be coordinated. However (and please correct me if I'm wrong) isn't SOAP's purpose to enable communication between a server and a.NET app? If so, it would seem to me that the.NET app (running on the inside of the firewall) and the server (running on the outside of the firewall) are certainly coordinated. And most likely, the.NET app that is inside your network got downloaded from the server that you're trying to connect to!
At which point we are not talking about SOAP over HTTP, we are talking about SOAP over reverse-bodged-you-just-invented-HTTP which bears no relationship to any standard ever. Nobody is proposing that model.
The proposal you make does nothing to control the class of attack you describe. Abusers will still be able to construct the type of attacks you describe if port 80 is open outgoing. All you would be doing is stopping the clients from running legitimately configured SOAP clients.
But as you correctly point out it is possible to filter the traffic on Content-Type. SOAP uses HTTP in exactly the way it was intended to be used I wrote the security profile for HTTP. Java on the other hand completely ignores the content-type field and does so deliberately to prevent filtering. So before heaping yet more criticism on Henryk and co who know what they are doing (Henryk was an editor of the HTTP spec), perhaps you would like to ask Gosling and Co why they decided to do their own thing?
Downloading active code on a user's browser, sandbox or no is a much riskier proposition than a SOAP call.
That is irrelevant. If you allow arbitrary outgoing requests, and their replies, then it's trivial to encapsulate an incoming request in the replies. Witness httptunnel [nocrew.org] which can be used to setup outgoing SSH connections, which in turn can be used with PPP over SSH to establish the entire IP protocol... INBOUND... All of this over port 80.
Which is why I am not impressed by the argument you make. Forget port 80 by the way, if you use SSL you prevent the firewall having any interaction! Do the initial SSL handshake then once you turn on encryption switch to using IP in IP encapsulation.
The attack you describe would require collusion between the sender and the receiver. So if SOAP ran over a SOAP specific port there would be nothing to prevent the sender and receiver colluding to layer it over HTTP on port 80.
Firewalls do not present a barrier to an attacker who has already penetrated a network. At best they provide a hinderance. The value of a firewall is preventing the initial attack.
I really think you need to examine SOAP, especially as it relates to RPC. When you make a request to SOAP, it's an incoming request over HTTP. Coming from an outside party to your ticket selling system to reserve a flight. That's the whole idea of published web services.
Any you would put a machine of that type providing an external service in your internal network???
You entirely miss the point, for every service there is also a client.
The port 80 / firewall issue has nothing to do with the server end. It is when the client is behind a firewall that you have a problem.
There is no firewall bypass issue at the service end, a company that is providing a published dotnet service will modify its firewall configuration to deploy its product. The problem with firewalls comes when the IT dept refuses to modify the firewall configuration to allow use of services provided externally.
If you think Adam and Bruce are offbase on security, you obviously have no concept of the capabilities, experience or dedication of either individual.
I know Adam and Bruce very well, they know me very well. I don't think either of them would claim that they had greater expertise or experience than I do, and in particular not on this particular topic. Certainly neither would expect the automatic deference to their views you appear to think due.
On this point they happen to be mistaken. Bruce is very rarely 'wrong' about security, that is I do not recall an instance of him calling a system secure when it was not, he is however quite frequently mistaken in describing a system as insecure when it is in fact secure. If he could learn to discuss them in private with the relevant designers before launching public attacks his reputation inside the security industry might match that outside.
The point in question is a sngle sentence paragraph tacked onto the end of a section. I suspect that it was an afterthought that they had not thought through in great detail. If they want to call me up and discuss it I can go through the detailed analysis I have.
The point is that one of the fundamental features of the IP suite is that unique services should run over unique ports. This has a wide variety of benefits, one of which is that you can SHUT IT DOWN AT THE FIREWALL
HTTP has by design (mine) the ability to tag content within the HTTP stream. Unless you have a packet filter as opposed to a firewall you should be able to select on the content types you allow into your company. This is why we invented HTTP Proxies.
However the issue you raise does not actually arise since a firewall should not be accepting incomming HTTP requests to the internal network in the first place. The only reason to open port 80 incomming on a firewall is if it is serving a DMZ in which case the machines are highly controlled and the issue of unauthorized servers should not exist.
I have no idea what are you talking about here. ftp is "built on telnet"?
Sounds whacky? It is true. I have implemented FTP several times. FTP uses two TCP channels, a control channel and a data channel. The control channel is layered over Telnet. The protocol model of FTP is you log into a remote machine and tell it to transfer files.
And FYI, SSH - OpenSSH at any rate - still had OpenSSL as a dependency
The history there was that back in the very distant past someone had the very good idea of developing a secure telnet and then had the very bad idea of basing the work on SSL 2.0. As he discovered just how broken SSL 2.0 was he fixed it and SSH diverged. In fact there are good reasons why you can't build secure telenet on SSL since SSL assumes that you can simply do a 1 for one swap at the transport layer and is designed arround a stream cipher. This lays you open to attacks like keystroke timing. For secure telnet you really want a block cipher, or if you do use RC4 throw out the first 1024 bytes of the cipherstream.
So, I should just let all the spammers, script kiddies and hackers (not crackers; I mean HACKERS) just break into my computer whenever they wanted. Do you understand ANYTHING about security?
Actually selling firewalls is a large part of my business. The point you don't understand is that people often buy firewalls as a substitute for security rather than a means of security. They want to tell their auditors they are secure, they don't actually want security.
There is very little point in buying a $100K firewall installation from me if you don't make sure there are no backdoors into your network. A gateway is no use at all without a fence. But the number of clients who fail to check their telephone networks for unauthorized dial up modems is large. Also depressing is the number of customers we go into where an expensive firewall has been installed but is configured insecurely. It is not unknown to find all ports open in both directions.
These days I try to get customers to buy a VPN with a firewall so that they can provide a controlled means of accessing the network from outside. The official rationale is that companies can save big by decomissioning their unreliable internal modem pools and switch to using a VPN and a national ISP with lots of POPs so the company doesn't have to pay long disatance telephone charges. While the numbers add up the real reason that the companies buy them is so that the CEO can read his company email over his cable modem.
Back at the start of the 1990s the general consensus in the computing industry was that UNIX could never succeed outside academia because it was chronically insecure.
It would be good if the people who spend so much time attacking Microsoft's security issues considered that UNIX generally and Linux in particular are not exactly fault free.
How can anyone who runs sendmail throw stones at Microsoft? sendmail is a textbook case in how to write software that can never be secure. The program breaks every single one of the rules Bruce and Adam set out. There are plenty of better alternatives, yet sendmail remains the default through sheer inertia (you might want to route some bang path UUCP or OSI mail sometime you know).
UNIX only became secure as a result of trial and error. There never was a security architecture worth a damn. For many years the main contribution to the security world from the UNIX security architecture folk was discouraging people from using shaddow password files.
The security model of all modern operating systems is based on the security model of MULTICS and comes from the age of the Multiple Access Computer. The security problem is defined in terms of a single machine that has multiple concurrent users. The addition of the network is an afterthought.
What this means is that very few of the security features in a modern O/S are actually of the slightest relevance to a machine running a Web server. In effect we end up with two parallel permissions structures, the one managed by the O/S and the one managed by the Web server.
Win2K and XP have Kerberos and PKI integrated into their core. The standard condfiguration supports IPSEC, S/MIME, SSL, Kerberos, Smartcard login, Encrypted File system. Measuring security in terms of cryptographic features Microsoft wins hands down (Microsoft are good on features).
Linux on the other hand is not in anywhere near such a good position. Security packages are available but it is left to the end user to integrate them.
Linux also lacks anything that resembles the 'Security Administration Guide' mentioned in the rainbow series books.
Security is not a binary condition. The problem I see for Linux is complacency. There are too many weenies out there whose knowledge of security is actually minimal who tell people Linux is secure because that is what they have been told. None of the O/S on the market are particularly secure. Windows has a great security architecture that the crappy applications completely bypass. UNIX has a crappy architecture and some very well tested applications whose security bugs have been largely eliminated by trial and error.
People in the OSS community can go arround telling each other that Linux will always be more secure than Windows if they like, but that won't make it true. Gates has essentially served notice that Microsoft is going to be upping the ante here. That does not mean that they will win, but a lot of work is going to have to be done if Linux is going to keep up. Fotunately it is not necessary to integrate PKIX into Linux as Microsoft did with Windows, the OSS community could skip a PKI generation and move straight to using new technology such as XKMS and SAML.
The idea of SOAP is to allow IT services to be exposed as remotely addressable and usable procedures. Essentially with every web service or SOAP receiver, you have written a brand new server that parses XML protocol messages to decide on action.
FUD
What you, Adam and Bruce appear to miss is that firewalls are rarely configured to allow incomming HTTP requests. If they are the requests are typically handled by a server located in a DMZ between two firewalls.
The firewall bypass problem is for outgoing requests. There is not actually a whole lot of difference in the security implications of an HTTP client posting a form in URL encoding and posting an XML document.
SOAP is just an RPC mechanism that happens to flow over HTTP, mostly because Dave Winer only knows one protocol -- HTTP. Mr. Winer didn't try to evade protocols, he just couldn't conceive of creating a different protocol for this application -- an error of omission, not commission.
One of the principal architects of SOAP was Henrick Frystick Nielsen, who certainly knows about more protocols than just HTTP since he implemented them all in the CERN libwww code.
The point is that running SOAP over SMTP or NNTP does not make a lot of sense except to looney email junkies who need a strong does of reality. SOAP over FTP makes no sense because FTP is a fundamentaly bodged protocol, it is less efficient that HTTP in every circumstance, it is also designed as a human/machine interface and is actually fairly brittle when used as a machine/machine interface due to different incompatible implementations and interaction between the ftp daemon and the file system semantics. The number of special case code paths for FTP in the libwww code is quite large. Some folk are trying to combine FTP and SSL which is not a good plan because FTP is actually built on Telnet and there are good reasons not to use SSL with Telnet which is why SSH is no longer based on SSL.
Henryk certainly knows about designing new protocols as well, he was one of the principal architects on HTTP-NG which people refused to use because HTTP was good enough for them.
SOAP actually layers over several transport protocols but the only one most people have any interest in is HTTP. There is a small interest in BEEP, but BEEP is a fairly new protocol that is probably only simple because nobody has used it yet and so we don't know what it lacks.
I don't have much sympathy for folk complaining about the use of the 'firewall bypass protocol'. Firewalls are like chastity belts, they are mainly bought by people who intend others to wear them and suffer their inconveniences. They are also like chastity belts in that they tend to be less effective than the purchaser imagines.
SOAP traffic is actually quite easy to detect in HTTP, just examine the Content-Type field. It is strange that Bruce should get so excited about this and say nothing about Java that deliberately disguises itself as application/binary to prevent firewall filtering (and yes I did suggest Gosling chage this before they release Java, they refused).
Looks like (at first glance) that the W3C have taken a cop-out route... "yes we'll keep things royalty free (but only if we can't find a good reason to make them royalty charged)".
That is not the position at all. You are talking typical Slashweenie nonsense driven by some innane paranoia.
The policy says the exact opposite of your claim. The presumption will be in favor of royalty free.
Why can't they take a stance and say that without exception patents registered by the w3c will become public domain property (by filling the patent it prevents any other group trying the same thing without the public interest)
The policy is not about patents filled by W3C, it is about patents filled by others, some of whom may be members, others who may not.
There are very few W3C members who actually want RAND terms, in fact I can only think of one that has advocated collecting royalties and that is IBM. There are quite a few W3C members who work in areas that are heavily patent encumbered, in many cases due to the negligence of the USPTO there are multiple overlaping patent claims.
What most companies in those encumbered areas do is to file lots of defensive patent collateral for trading purposes. In most cases everyone holding the patents realise that ultimately the probability they are enforceable is quite slim but they can't disarm unless everyone else does. A quite reasonable objective of the W3C patent policy is to encourage negotiation of patent pacts so that a royalty free license is available to anyone who is willing to reciprocate.
Incidentaly, the reason I apply for patents on technology that we intend to make royalty free is to block attempts by others to do so. Whenever I publish a specification some snot comes out of the woodwork and runs off to the USPTO with a perjured patent application claiming it was their idea. Then they try to sell my idea back to me. I am getting so fed up with this that we are actually thinking of bringing a civil perjury suit against the next perpetrator.
The theory of patent law is to encourage use of new ideas. In fact the effect is now the reverse. I spend a lot of time looking at old mailing lists etc. for OLD ideas that might be tweaked to answer a current need.
The point that posters appear to be missing is that despite holding 80 person shredding parties enough has emerged about the activities of Arthur Anderssen and Enron to cause as much damage as could possibly happen. If the investigators can't get someone for fraud they will get them for shredding.
The Enron documents that were shredded are likely the early drafts of the audit report. While it is quite likely that there will be electronic copies of the destroyed documents what the investigators would probably most like to get their hands on would be draft copies with handwritten annotations. It is unlikely in the extreeme that anyone wrote a document that was incriminating on its own, but quite likely that incriminating marginalia existed.
BTW in addition to their involvement in the Sunbeam and Waste Management debacles Anderssen were until recently blacklisted by the UK government who held them responsible for their losses in the Delorean fiasco.
What do you not like about Thomas? If it is about Dr. Hill's harassment complaints, most people realize now that was the same business as the Paula Jones brouhaha -- a sex-driven partisan attack with no evidence to back it up.
The accusations were far more convincing to me than the evasions of Thomas. The GOP operative who organized the smear attack on Hill has since repented and admitted that it was a partisan hatchet job.
Besides that, I tend to think that the job of Supreme Court Justices requires that the best you can say of them should be something more than 'not a proven sexual offender'.
As a liberal, I think what happened to Bork was just plain wrong. Ashcroft, on the other hand, deserved everything he got and more; he has abused his position disgracefully in the past, and my objection to him isn't his ideology, but his willingness to subvert both his position and the law to further his own agenda.
Given Ashcroft's performance thus far I suspect that more than a few of the administration wish he had been borked.
Ashcroft is accident prone, never a good thing for a politician. For no good reason he pushed through a half baked idea of military tribunals which Rumsfeld has quietly and deliberately crushed. If any tribunals do take place they wil now be run by rules set by Rumsfeld.
Another accident prone individual the Administration will probably regret is Olson. During his first spell in government Olson initiated a ridiculous dispute with Congress over executive privillege. He is now busy trying to make sure that the details of Cheney's discussions with Enron CEO Lay are dealt with in the same manner.
Slashdot Mirror
Ahh so what was called Internet time was no more than the phenomena of companies releasing what used to be called Alpha release software to the public?
Reading the article I think that Cringely's biggest problem is that he does not understand how long it takes to get technology from a proof of concept to a working system.
With the Web it has taken ten years and counting to get this far. Idiot pumpers like Meaker and Blodget aside, Internet time runs at 1 for one with GMT at best.
I first heard about ISDN in the 80's, ten years later people started to get ISDN phone lines. Likewise with DSL the basic ideas were floating arround in the early 90s but are still not fully baked for deployment.
It does not seem unreasonable that people will be rolling out much faster cable networks in (say) 2010 or so. I don't think it is going to happen on any larg scale before then however. The DOCSIS standard has only just been developed and it will take at least 3 years for any radical redesign to make it into a spec and another 2 to get into production, then there will be the inevitable delay as results from trial deployments are assesed and so on.
What cringely and co miss is that athough the majority of the cost of a fully deployed system is at the consumer end s not where the killer costs lie. To roll out broadband access in a town you first have to buy lots of gear that typically comes with five or six figure price tags. You have to buy that gear whether one person buys service or ten thousand. The client end costs are not so much of a problem because each customer pays a subscription.
That is why the cable companies partnered with the losers @Home to deploy broadband. The cable cos were not prepared to gamble their capital on the success of broadband. @home was. Of course the minute that there was proof of the business plan @home became surplus to requirements
So yeah, wavelets, whatever, but at the moment the bandwidth in the last mile is not the bottleneck. Nor is the bottleneck in any of the pipes. There were four companies that deployed fibre backbones over the last five years, each of which has more capacity than the country could use before 2015. It is the switching capacity that is expensive and that comes down to pricey silicon and probably always will. If you have computing technology of power X you end up with switching nodes that require processing power of many, many X.
It does not appear very likely that the judge had any choice in the matter. Depositions are taken in private in all federal cases unless there is a specific requirement that they be public.
Once Microsoft protested the state AGs were bound to request the opposite regardless of what they would otherwise have requested since they could then grandstand with the openess claim.
Given that the state AGs are mostly political hacks and many come from states where a lot of voters work for companies that compete against Microsoft the scope for grandstanding in open depositions would have been huge. While the Federal government was running the case the state AGs had to take a back seat.
Ashcroft on the other hand is the type of political hack who loses an election to a dead man then spends $8000 of tax payers money having the statues in his HQ covered in a Burqua.
I once saw a shaddowing controller fail in such a way that it managed to corrupt both of the RAID 5 arrays it was driving. Had to bring the system back up from the first level backup.
Soon after that we switched to using EMC gear.
Same way we used to do it in the cinema when you had a missing frame. If you stick a triangular piece of masking tape over the splice the audience never realises that it was there. The triangle causes the sound levels to be faded to zero and back again in an instant (well probably 1/100th sec).
The human ear can't detect that sort of thing because at the end of the day its actually doing a mechanical version of a fourier transform on the audio signal and drop-outs of that sort don't carry too well.
If you start doing the trick too often there is a significant chance that you miss soething important. Imagine listening to the 1812 overture with random pieces missing, so you don't hear the canon shot etc.
It is possible that they use some other sort of interpolation to smooth over the lost time but then you start to lose the sync between the actors lips and the sound track and it will start to look like Jackie Chan.
How many keys then
A more likely reason for not turning on optimization would be not wanting to wait for the optimizer to run. Another good reason is that it is often harder to debug optimized code.
At one time though the most frequent reason to avoid the optimizer was that many were buggy as heck and would introduce all kinds of bugs based on an imperfect understanding of how the program work. This was particularly the so with Fortran compilers where the derranged semantics of the language often bit the optimizer hard. It would also bite the programers on many occasions who would make use of common blocks that was outlawed under the Geneva convention.
Intel has sold its compiler expertise for years. There is Intel code in most of the commercial compilers in use. I don't see why Intel should give code away to Microsoft to sell in Visual Studio.
Equally, there is little point in having an internal optimization team that can't beat an external team with no advance knowledge of the processor architecture.
What you mean is that a SOAP client hooked up to (say) an XKMS trust service is subject to a greater degree of risk than a Web browser surfing Slashdot. Well Duuhhh!!!!
The protcol is irrelevant at that stage. The vulnerability comes from the fact that a large number of Web services are intended to support some pretty high trust applications. For example people are entirely serious about using Web services to move very large sums of money arround. XKMS is designed to be used to validate public keys used (amongst other things) to authorize very high value transactions.
But the people who are managing that type of application are quite aware of the risks involved. The risks are intrinsic to the application and the use of Web Services is incidental.
Nobody raised a fuss when we layered OCSP over HTTP - and that protocol was reviewed by pretty much the whole IETF security area.
So follow the advice Bruce is giving to MSFT, ship the product safe by default. Take out sendmail which has been a festering sore and slot in something that deserves the default slot.
>I think you meant "encouraging people to use shadow password files".
No, until the first copies of crack started to circulate the issue would regularly start flamewars on the security lists. The original description of the UNIX password feature made a big deal of the fact that the password file was world readable. The argument Moriss used was that read protecting the password file was 'security through obscurity'.
Even after crack appeared it took quite a while for people to realise that the exhaustive search attack was becomming practical.
[sendmail discussion] Never is a long time. What box-breaching flaws are in the latest release? Oh, you were referring to those older releases still installed all over the place.
sendmail is insecure for the same reason that Outlook is insecure, the program provides an excessive and unnecessary degree of complexity. The vulnerability in sendmail is the complex macro rewrite rule engine. The vulnerability in Outlook is that it will execute active code in email.
The problem with both pieces of code is akin to radioactivity. No matter how long you wait there will always be some level of insecurity. The insecurity is there because the program does something that is a fundamentally bad idea.
Swapping out sendmail for one of the excellent alternatives is a much better solution than upgrading. Equally running the 'turn off active content' patch on outlook is a good plan.
They were invited. In fact the Web development team spent a lot of time and effort getting Microsoft to support the Web and deploy a browser.
Now they are going to bully their way into the security market, in orde to provide an integrated solution?
Microsoft already provide one of the most comprehensive cryptographic security packages out their. Windows 2000 implements most of the X.509/PKIX specification and the IPSEC, SMIME and SSL protocols, they also provide an encrypting file system
The problem with Microsoft is not that they fail to provide security features, it is that they also throw in some of the most amazingly braindamaged insecure ones.
For example, if Microsoft removed the scripting features from Outlook most of the Microsoft security issues would be eliminated at a stroke. If Microsoft eliminated scripting from Word, Excell etc the number of security issues would be cut in half again. The fondness of Redmond engineers for active code is their major security weakness.
It is a weakness that is not limited to Redmond either. Netscape's addition of Javascript to HTML was pretty gratuitous. I have yet to see any feature achieved with an active code platform perpetrated by Microsoft, Sun or Netscape that provides more benefit to the user than the programer.
The difference is far from subtle, the major difference between CGI and Web Services is that in the early days of CGI people would have cshell scripts processing the queries.
So in a short time people discovered that you could cause all sorts of programs to be run simply by sending a query of the form http://xx...xx?a=x;rm+-rf+* which would result in some script executing
greet x;rm -rf *
Give or take the correct URL escape hackery.
Rob and Ari discovered the joys of shared libraries pretty soon after their CGI hack. OK CGI is easier to get started in than the Apache or NSAPI plug in architecture, but it is a lot more secure. What do people use though?
The fact that there are still books arround with three inch spines and the letters CGI on the front cover selling by the hundreds in Frys tells me that there are plenty of folk using what was a one night hack by two undergrad students who have since mended their ways. Even so those same folk will go off and throw stones at Mr Softy.
Incidentaly I was in the next room when Ari wrote the CGI spec and I can assure you that the idea that there might be a security issue did not occur to him when he was writing it.
The difference is that at least on the client side is that if I hack a website with SOAP web services the results can now affect the software running locally. Thus manipulating software on the client side to do things they were not intended to do.
No, this is not the difference. In IIS the Web service runs as just another back-end service provider.
SOAP does make it easier to export a DLL library to the Web. So if an attacker got control of a machine with Visual Studio .NET they could cause the individual all sorts of grief by exporting their system DLLs as SOAP services, but there are already trojans that allow execution of arbitrary code and the firewall should not allow incomming HTTP requests on the internal net in any case. So yes SOAP provides an additional and somewhat more artistic way to torment a machine that has been captured, but it does not introduce a new way to torment a machine.
Try adding one to each letter in VMS...
The similarities between WNT and VMS are well known and hardly suprising since Dave Cutler was lead architect on both. I seem to recall ACLs are earlier, didn't Butler Lampson invent them in Multics or something?
Anyway the point Butler always makes when ACLs are discussed is that they are too granular. What you really want to be able to do is to associate a named security policy with the actual resources (files, devices, etc. etc.) and then have the ACL rules stored in the policy. This has two major effects, first it makes the system more manageable since you don't have to spend time propagating out all your ACL changes, secondly the O/S can cache the result of evaluating the ACL which saves a lot of time when doing things like directory copy operations.
VMS actually introduced a structure like this called a rights identifier, however it appeared after Cutler left so it may have been one of the features he always hated and had kept out as long as possible.
You gave one example that is relatively easy to detect, I countered with a more powerful example that is impossible to detect.
The point that you apear to be determined to miss is that a firewall does not and cannot provide a meaningful control against the attack you describe. It does not do that today and it will not tommorow, whether SOAP runs over port 80 or no.
Again, the problem with firewalls is that they are considered by the naive to be a solution to every security solution ever. Like all security tools they have a very specific and narrow use.
The attack that I describe does require that the sender and receiver be coordinated. However (and please correct me if I'm wrong) isn't SOAP's purpose to enable communication between a server and a .NET app? If so, it would seem to me that the .NET app (running on the inside of the firewall) and the server (running on the outside of the firewall) are certainly coordinated. And most likely, the .NET app that is inside your network got downloaded from the server that you're trying to connect to!
At which point we are not talking about SOAP over HTTP, we are talking about SOAP over reverse-bodged-you-just-invented-HTTP which bears no relationship to any standard ever. Nobody is proposing that model.
The proposal you make does nothing to control the class of attack you describe. Abusers will still be able to construct the type of attacks you describe if port 80 is open outgoing. All you would be doing is stopping the clients from running legitimately configured SOAP clients.
But as you correctly point out it is possible to filter the traffic on Content-Type. SOAP uses HTTP in exactly the way it was intended to be used I wrote the security profile for HTTP. Java on the other hand completely ignores the content-type field and does so deliberately to prevent filtering. So before heaping yet more criticism on Henryk and co who know what they are doing (Henryk was an editor of the HTTP spec), perhaps you would like to ask Gosling and Co why they decided to do their own thing?
Downloading active code on a user's browser, sandbox or no is a much riskier proposition than a SOAP call.
Which is why I am not impressed by the argument you make. Forget port 80 by the way, if you use SSL you prevent the firewall having any interaction! Do the initial SSL handshake then once you turn on encryption switch to using IP in IP encapsulation.
The attack you describe would require collusion between the sender and the receiver. So if SOAP ran over a SOAP specific port there would be nothing to prevent the sender and receiver colluding to layer it over HTTP on port 80.
Firewalls do not present a barrier to an attacker who has already penetrated a network. At best they provide a hinderance. The value of a firewall is preventing the initial attack.
Any you would put a machine of that type providing an external service in your internal network???
You entirely miss the point, for every service there is also a client. The port 80 / firewall issue has nothing to do with the server end. It is when the client is behind a firewall that you have a problem.
There is no firewall bypass issue at the service end, a company that is providing a published dotnet service will modify its firewall configuration to deploy its product. The problem with firewalls comes when the IT dept refuses to modify the firewall configuration to allow use of services provided externally.
If you think Adam and Bruce are offbase on security, you obviously have no concept of the capabilities, experience or dedication of either individual.
I know Adam and Bruce very well, they know me very well. I don't think either of them would claim that they had greater expertise or experience than I do, and in particular not on this particular topic. Certainly neither would expect the automatic deference to their views you appear to think due.
On this point they happen to be mistaken. Bruce is very rarely 'wrong' about security, that is I do not recall an instance of him calling a system secure when it was not, he is however quite frequently mistaken in describing a system as insecure when it is in fact secure. If he could learn to discuss them in private with the relevant designers before launching public attacks his reputation inside the security industry might match that outside.
The point in question is a sngle sentence paragraph tacked onto the end of a section. I suspect that it was an afterthought that they had not thought through in great detail. If they want to call me up and discuss it I can go through the detailed analysis I have.
HTTP has by design (mine) the ability to tag content within the HTTP stream. Unless you have a packet filter as opposed to a firewall you should be able to select on the content types you allow into your company. This is why we invented HTTP Proxies.
However the issue you raise does not actually arise since a firewall should not be accepting incomming HTTP requests to the internal network in the first place. The only reason to open port 80 incomming on a firewall is if it is serving a DMZ in which case the machines are highly controlled and the issue of unauthorized servers should not exist.
I have no idea what are you talking about here. ftp is "built on telnet"?
Sounds whacky? It is true. I have implemented FTP several times. FTP uses two TCP channels, a control channel and a data channel. The control channel is layered over Telnet. The protocol model of FTP is you log into a remote machine and tell it to transfer files.
And FYI, SSH - OpenSSH at any rate - still had OpenSSL as a dependency
The history there was that back in the very distant past someone had the very good idea of developing a secure telnet and then had the very bad idea of basing the work on SSL 2.0. As he discovered just how broken SSL 2.0 was he fixed it and SSH diverged. In fact there are good reasons why you can't build secure telenet on SSL since SSL assumes that you can simply do a 1 for one swap at the transport layer and is designed arround a stream cipher. This lays you open to attacks like keystroke timing. For secure telnet you really want a block cipher, or if you do use RC4 throw out the first 1024 bytes of the cipherstream.
Actually selling firewalls is a large part of my business. The point you don't understand is that people often buy firewalls as a substitute for security rather than a means of security. They want to tell their auditors they are secure, they don't actually want security.
There is very little point in buying a $100K firewall installation from me if you don't make sure there are no backdoors into your network. A gateway is no use at all without a fence. But the number of clients who fail to check their telephone networks for unauthorized dial up modems is large. Also depressing is the number of customers we go into where an expensive firewall has been installed but is configured insecurely. It is not unknown to find all ports open in both directions.
These days I try to get customers to buy a VPN with a firewall so that they can provide a controlled means of accessing the network from outside. The official rationale is that companies can save big by decomissioning their unreliable internal modem pools and switch to using a VPN and a national ISP with lots of POPs so the company doesn't have to pay long disatance telephone charges. While the numbers add up the real reason that the companies buy them is so that the CEO can read his company email over his cable modem.
It would be good if the people who spend so much time attacking Microsoft's security issues considered that UNIX generally and Linux in particular are not exactly fault free.
How can anyone who runs sendmail throw stones at Microsoft? sendmail is a textbook case in how to write software that can never be secure. The program breaks every single one of the rules Bruce and Adam set out. There are plenty of better alternatives, yet sendmail remains the default through sheer inertia (you might want to route some bang path UUCP or OSI mail sometime you know).
UNIX only became secure as a result of trial and error. There never was a security architecture worth a damn. For many years the main contribution to the security world from the UNIX security architecture folk was discouraging people from using shaddow password files.
The security model of all modern operating systems is based on the security model of MULTICS and comes from the age of the Multiple Access Computer. The security problem is defined in terms of a single machine that has multiple concurrent users. The addition of the network is an afterthought.
What this means is that very few of the security features in a modern O/S are actually of the slightest relevance to a machine running a Web server. In effect we end up with two parallel permissions structures, the one managed by the O/S and the one managed by the Web server.
Win2K and XP have Kerberos and PKI integrated into their core. The standard condfiguration supports IPSEC, S/MIME, SSL, Kerberos, Smartcard login, Encrypted File system. Measuring security in terms of cryptographic features Microsoft wins hands down (Microsoft are good on features).
Linux on the other hand is not in anywhere near such a good position. Security packages are available but it is left to the end user to integrate them. Linux also lacks anything that resembles the 'Security Administration Guide' mentioned in the rainbow series books.
Security is not a binary condition. The problem I see for Linux is complacency. There are too many weenies out there whose knowledge of security is actually minimal who tell people Linux is secure because that is what they have been told. None of the O/S on the market are particularly secure. Windows has a great security architecture that the crappy applications completely bypass. UNIX has a crappy architecture and some very well tested applications whose security bugs have been largely eliminated by trial and error.
People in the OSS community can go arround telling each other that Linux will always be more secure than Windows if they like, but that won't make it true. Gates has essentially served notice that Microsoft is going to be upping the ante here. That does not mean that they will win, but a lot of work is going to have to be done if Linux is going to keep up. Fotunately it is not necessary to integrate PKIX into Linux as Microsoft did with Windows, the OSS community could skip a PKI generation and move straight to using new technology such as XKMS and SAML.
FUD
What you, Adam and Bruce appear to miss is that firewalls are rarely configured to allow incomming HTTP requests. If they are the requests are typically handled by a server located in a DMZ between two firewalls.
The firewall bypass problem is for outgoing requests. There is not actually a whole lot of difference in the security implications of an HTTP client posting a form in URL encoding and posting an XML document.
One of the principal architects of SOAP was Henrick Frystick Nielsen, who certainly knows about more protocols than just HTTP since he implemented them all in the CERN libwww code.
The point is that running SOAP over SMTP or NNTP does not make a lot of sense except to looney email junkies who need a strong does of reality. SOAP over FTP makes no sense because FTP is a fundamentaly bodged protocol, it is less efficient that HTTP in every circumstance, it is also designed as a human/machine interface and is actually fairly brittle when used as a machine/machine interface due to different incompatible implementations and interaction between the ftp daemon and the file system semantics. The number of special case code paths for FTP in the libwww code is quite large. Some folk are trying to combine FTP and SSL which is not a good plan because FTP is actually built on Telnet and there are good reasons not to use SSL with Telnet which is why SSH is no longer based on SSL.
Henryk certainly knows about designing new protocols as well, he was one of the principal architects on HTTP-NG which people refused to use because HTTP was good enough for them.
SOAP actually layers over several transport protocols but the only one most people have any interest in is HTTP. There is a small interest in BEEP, but BEEP is a fairly new protocol that is probably only simple because nobody has used it yet and so we don't know what it lacks.
I don't have much sympathy for folk complaining about the use of the 'firewall bypass protocol'. Firewalls are like chastity belts, they are mainly bought by people who intend others to wear them and suffer their inconveniences. They are also like chastity belts in that they tend to be less effective than the purchaser imagines.
SOAP traffic is actually quite easy to detect in HTTP, just examine the Content-Type field. It is strange that Bruce should get so excited about this and say nothing about Java that deliberately disguises itself as application/binary to prevent firewall filtering (and yes I did suggest Gosling chage this before they release Java, they refused).
That is not the position at all. You are talking typical Slashweenie nonsense driven by some innane paranoia.
The policy says the exact opposite of your claim. The presumption will be in favor of royalty free.
Why can't they take a stance and say that without exception patents registered by the w3c will become public domain property (by filling the patent it prevents any other group trying the same thing without the public interest)
The policy is not about patents filled by W3C, it is about patents filled by others, some of whom may be members, others who may not.
There are very few W3C members who actually want RAND terms, in fact I can only think of one that has advocated collecting royalties and that is IBM. There are quite a few W3C members who work in areas that are heavily patent encumbered, in many cases due to the negligence of the USPTO there are multiple overlaping patent claims.
What most companies in those encumbered areas do is to file lots of defensive patent collateral for trading purposes. In most cases everyone holding the patents realise that ultimately the probability they are enforceable is quite slim but they can't disarm unless everyone else does. A quite reasonable objective of the W3C patent policy is to encourage negotiation of patent pacts so that a royalty free license is available to anyone who is willing to reciprocate.
Incidentaly, the reason I apply for patents on technology that we intend to make royalty free is to block attempts by others to do so. Whenever I publish a specification some snot comes out of the woodwork and runs off to the USPTO with a perjured patent application claiming it was their idea. Then they try to sell my idea back to me. I am getting so fed up with this that we are actually thinking of bringing a civil perjury suit against the next perpetrator.
The theory of patent law is to encourage use of new ideas. In fact the effect is now the reverse. I spend a lot of time looking at old mailing lists etc. for OLD ideas that might be tweaked to answer a current need.
The Enron documents that were shredded are likely the early drafts of the audit report. While it is quite likely that there will be electronic copies of the destroyed documents what the investigators would probably most like to get their hands on would be draft copies with handwritten annotations. It is unlikely in the extreeme that anyone wrote a document that was incriminating on its own, but quite likely that incriminating marginalia existed.
BTW in addition to their involvement in the Sunbeam and Waste Management debacles Anderssen were until recently blacklisted by the UK government who held them responsible for their losses in the Delorean fiasco.
The accusations were far more convincing to me than the evasions of Thomas. The GOP operative who organized the smear attack on Hill has since repented and admitted that it was a partisan hatchet job.
Besides that, I tend to think that the job of Supreme Court Justices requires that the best you can say of them should be something more than 'not a proven sexual offender'.
Given Ashcroft's performance thus far I suspect that more than a few of the administration wish he had been borked.
Ashcroft is accident prone, never a good thing for a politician. For no good reason he pushed through a half baked idea of military tribunals which Rumsfeld has quietly and deliberately crushed. If any tribunals do take place they wil now be run by rules set by Rumsfeld.
Another accident prone individual the Administration will probably regret is Olson. During his first spell in government Olson initiated a ridiculous dispute with Congress over executive privillege. He is now busy trying to make sure that the details of Cheney's discussions with Enron CEO Lay are dealt with in the same manner.