You're missing the point. Brown is not apologizing for Britain having behaved *illegally*, or for having prosecuted Turing. The law was applied as written at the time (I'm assuming; I haven't checked). He's apologizing for Britain's treatment of Turing, period. The law was unjust, and the results horrific. Britain is recognizing this and doing the only thing it can at this point: express its regret.
The problem is that CapitalOne's web server does not supply the certificate for the intermediate CA which issued the server's cert, so Firefox can't make a chain back to the root (which it does have). The reason it works in some other browsers, is that the web server cert itself contains a pointer to the needed certificate embedded in it; the browsers in which it works fetch the intermediate cert from there; Firefox simply doesn't do that. It actually works in the latest release of Firefox, as well.
If you allow shell access, then of course such restrictions are ineffective, since people can install/use their own forwarders, as you did. To make them effective, you restrict the relevant accounts to port forwarding only.
There's a lot of exaggeration and vagueness on both sides of this little tempest. What suffices for one enterprise may not for another, so it is certainly silly for ssh.com to claim that OpenSSH is not "enterprise-class" -- as Theo and others rightly point out, OpenSSH is used successfully in many large contexts. On the other hand, it is a fact that Tectia has a number of features OpenSSH lacks, some of which are particularly relevant to large organizations (which is not the same as simple widespread use). Here are a few of them:
* PKI support
Tectia can use X.509 certificates for both client and server authentication. To add a new SSH server or change an existing one's host key, all you need do is issue a certificate for it. Clients need only have a copy of a single public key: the issuing CA certificate. No constantly shifting mess of per-user and per-host known-host files to try to keep in sync, no spurious "unknown host" or "host key changed messages" confusing users and teaching them to ignore security warnings. It just works.
For client authentication, there are no burgeoning copies of authorized_keys files lying around, unmanaged, needing to be individually tracked down whenever you want to turn off someone's access: instead, you can simply revoke the user's certificate. And flexible rules can grant access based on certificate attributes, like "anyone in the Foo Department can log into this host."
The distributed-trust problem has been addressed abstractly by systems like PKI and Kerberos. In a large (or even medium) scale environment, you want to tie applications such as SSH into these systems, not have each one use its own ad-hoc mechanism.
Note that both OpenSSH and Tectia support Kerberos. There is some variation in how well they use it to address the above problems, though, and I won't get into that here.
* Greater configuration flexibility
With the Tectia SSH server you can:
+ Modify almost all server parameters based on the client hostname and
address, or properties of the requested account (username and group
membership). Thus you can arrange that, accounts in one group permit
password authentication, while those in another group require
public-key -- or that connections coming from your internal network
allow a wide range of ciphers, while those coming from the outside
require a smaller, stronger set. You can accomplish some of this type
of thing with OpenSSH, but generally you have to run multiple
instances of the server on different ports.
+ Exert finer-grained control over what kinds of SSH services you
provide. You can forbid terminal access while still allowing sftp,
for example, by simply rejecting the corresponding SSH protocol
requests (shell and exec channels), rather than resorting to custom
shells or other hacks that have unwanted side effects.
+ Control port forwarding with ACLs that include permit/deny statements
and patterns matching user, target hostname, IP address, etc.
+ Require multiple forms of authentication for access (e.g. password and
public-key).
* SOCKS support for outgoing SSH connections (note this is different from
the OpenSSH -D feature, which Tectia has also).
* "chroot"-ed logins
* integrated support for RADIUS authentication
* Support for Windows-native Kerberos. Although OpenSSH can be built with
Kerberos support on Windows (with Cygwin), it does not
Kerberos isn't designed for the Internet. You need to set it up explicitly for each trust domain on each client computer. So users can't just pull out their personal laptops and use them to log in...
I'm afraid your entire point here is just technically false. Kerberos only requires host setup with if the host is a server; that is, to run a kerberized service on it, you need to establish a shared key for the service principal with the Kerberos system (KDC) and store it on the host where the corresponding server can find it (e.g./etc/krb5.keytab). A Kerberos client can run anywhere and does not require a prior host connection with the realm at all. You *can*, in fact, do exactly what you describe here as impossible: connect your laptop to a network and type "kinit user@REALM" to get credentials, then use a kerberized application such as OpenSSH. The Kerberos software can find a KDC for "REALM" from the DNS (assuming the appropriate rr's are available). Note that this is secure despite the insecurity of the DNS in general, since Kerberos is a shared-secret system: since you share a secret with the KDC (essentially your password), you can validate the KDC's response.
One side job that doesn't have the problem of clashing with office hours is writing. Over the past few years, I have co-authored two O'Reilly books: "SSH, The Secure Shell (The Definitive Guide)" and "The Linux Security Cookbook." In addition to a substantial second income, I have had several follow-on writing and consulting opportunities (white papers, articles, etc.). Of course, there's the question of whether you want to spend even more time sitting in front of a computer in your off hours...
shouldn't decisions based on taxpayer money usually be based on cost analysis?
They should be based on sound analysis, surely, but cost is only one component. There are plenty of other extremely good reasons to prefer -- indeed, to demand -- open source in government. The following letter, purportedly from a Peruvian official to a MS exec, lays them out very well:
http://www.theregister.co.uk/content/4/25157.htm l
... in which he reflects on their founding slogan of 'Tech News First' and their commitment to that going forward... Thoughts or opinions, anyone?"
I really hate that bit of idiotic business-speak, "going forward." We should all feel incentivized to leverage our existing linguistic infrastructure, and architect a solution using existing word-assets rather than repurposing them -- going forward.
This is a shortsighted and ultimately ineffective approach to security.
To point out one simple problem: when you mention "SMTPS," you are apparently thinking of SMTP over SSL on the alternate port 465. But this method of securing SMTP (and other protocols) is deprecated by RFC 2595, section 7, in favor of STARTTLS (and similar mechanisms). Requiring people to use a VPN to do such a simple thing as submit authenticated mail to a remote server is overly complicated, burdensome, and inappropriate.
More generally, over time this approach simply won't result in better security, and you will have extra annoyance, complexity, and breakage with no upside. As long as you can exchange arbitrary bits between two hosts, in some way, there's a channel that can be multiplexed to do anything you like, and get around any exterior restriction. At first, this may result in some advantages, since only a small number of techies will know how to get around it. However, it is self-defeating. If it results in any significant inconvenience, a workaround will be codified into common software, and the restriction will shortly become meaningless. HTTP is a perfect example. Years ago, firewalls appeared which blocked all inbound TCP ports except HTTP -- the rationale being, HTTP is relatively harmless, most all it does is ask to see some files; configure the web server and file security properly, and what's to worry?
Of course, then distributed computing models became more widespread, and people wanted to do things like send information as well as receive it, do RPC, etc. -- but the only port vendors could be sure would be open was 80. So they turned on PUT and invented things like DCOM and SOAP -- and now port 80 is just as dangerous to have open as if we had these various things on their own ports and had them all open; there is no difference.
This process will just repeat itself. Security is not gained by blocking packets based on crude, low-level indicators like TCP port numbers. All you get is the same security problems you had before, only now with a network that is overly complex, difficult to use, and prone to breakage, because of all the random restrictions in place (unnecessary NAT, simplistic firewalls, etc.).
One of the more irritating tactics of posters with nothing to say is to attack a statement based on an interpretation they know to be wrong. It's like the Spelling Police
You insinuate that I know my interpretation of the situation to be "wrong," but you have no credible personal basis on which to make that claim (since you are posting anonymously), and present no facts to back it up. Your post is hence without merit. As for what this could possibly have to do with correcting spelling, that's anyone's guess, but it doesn't seem very interesting...
Face it. There is stolen code in Linux. How much and how severe the value of the theft is to be determined but that there was theft is almost certain...
One of the more irritating tactics in the war of misinformation about IP being waged by organizations like SCO, the RIAA, etc., is the intentional misuse of language. Things like trying to make "filesharing" a dirty word in itself, when in fact there is of course nothing more immoral about copying files than there is about using a photocopier -- it depends on what you're copying and what you're doing with it.
Another example is the rampant incorrect use of the terms "theft," "stealing," etc., intended to make the alleged perpetrators sound like sordid, common criminals. Copying a file, no matter what the IP issues surrounding it, is simply not "theft." From Webster's dictionary:
Theft, n... (Law) The act of stealing; specifically, the felonious taking and removing of personal property, with an intent to deprive the rightful owner of the same; larceny.
Note: To constitute theft there must be a taking without the owner's consent, and it must be unlawful or felonious; every part of the property stolen must be removed, however slightly, from its former position; and it must be, at least momentarily, in the complete possession of the thief. See Larceny, and the Note under Robbery.
Copying data does not deprive the owner of the original of that data. It has not been removed, and he still has access to it and use of it. There might be copyright infringement, and there might not be, but it is not theft.
It's hard to believe this is an issue in the year 2003. We've had good device-, resolution-independent graphics systems for decades (e.g. Display PostScript, NeWS, etc.). It is an obviously, profoundly stupid thing to do to measure anything for display, at a high level, in units tied to something as hardware-dependent as pixels. And yet, here we are, discussing this problem as if it were some kind of deep technical issue -- and people are afraid to buy better monitors because they have to squint at them, because the software running the displays of the major OS's still makes mistakes we learned how to avoid in the 70's.
Open only the ports you need and make sure the software running on them is secure.
This is a naive and misleading suggestion. First, you cannot "make sure" any software is "secure." Second, this does not address the myriad vulnerabilities inherent in the software people run every day which are not network servers: mail readers vulnerable to viruses, web browsers vulnerable to many kinds of malicious content, etc. For both these reasons and more, security must be a multi-level, ongoing process -- not just "set up a firewall and you're secure!"
Another way to do that is to use RFC - Remote Filesystem Checker (look it up on freshmeat) which scp's a static binary of your IDS of choise to the machine that needs checking, runs it, and compares with the local DB of the 'trusted' machine. Much cheaper than buying specialized hardware.
Much cheaper, and not at all the same thing. This is not equivalent, which is made clear in the sequence of examples in the book of which this is an excerpt. "Copying over a static binary" does not guarantee it will do what you want, since if it's hacked the machine in question may have had its kernel or program loader altered so that the "binary" does not do what you think it will. Or the tool you use to "copy [it] over" may have been altered, or the network traffic involved in comparing the local and remote signatures may be compromised. Etc. You may consider these unlikely attacks, and I agree, but they are possible, and this recipe is at the higher end of paranoia attempting to address these possibilities.
Of course, if the running kernel has been altered without changing any disk files, then you've really got a problem...
Um, how about:... sidestep a typically insidious provision...
OK, this is absurd. Judging by the general arrogance level, poeple who post to Slashdot obviously think of themselves as pretty smart. It's not very convincing, when the editing, spelling, grammar, etc. in the posts is so consistently bad! And do the Slashdot folks really think their publication can be taken seriously, when it's apparently edited by a bunch of not-very-well-educated 6th-graders? Wake up.
Maybe that in a forum mostly used by men, we have a total and absolute disgust of other men who suck another man's dick or to fuck another man in the ass.
Maybe you do, but then you've got some kind of weird hangup. I think it's more likely that "we" have disgust for people who think like you... fortunately though, your brand of intolerance is fading away.
To make a long story short -- I had to upgrade the BIOS. After that, the nVidia board worked perfectly.
Thanks for all the input; without the assurance that these cards did actually work in this setup, I would not have gone back and done the extra testing/searching that turned up the solution.
It's encouraging that you both got this to work with this (relatively inexpensive) card; however, I'm puzzled why I didn't work for me. As I said, I did try the Xtasy nVidia GeForce4 Ti. I got no picture at all, ever -- just single glimpse of a blinking cursor at power-on, which immediately disappeared, then a blank screen. I also got this response from VisionTek support (the card maker):
GeForce4 Ti4600 which used on Apple computers has different design then Ti4600 for PCs. For PC, the maximum supported resolution for DVI is 1280x1024.
... but since you are both claiming it works, I suppose I will discount this. Are you using AGP or PCI?
I know about the monitor control issue, but since I have a Mac connected also, this isn't a problem...
Slashdot Mirror
You're missing the point. Brown is not apologizing for Britain having behaved *illegally*, or for having prosecuted Turing. The law was applied as written at the time (I'm assuming; I haven't checked). He's apologizing for Britain's treatment of Turing, period. The law was unjust, and the results horrific. Britain is recognizing this and doing the only thing it can at this point: express its regret.
The problem is that CapitalOne's web server does not supply the certificate for the intermediate CA which issued the server's cert, so Firefox can't make a chain back to the root (which it does have). The reason it works in some other browsers, is that the web server cert itself contains a pointer to the needed certificate embedded in it; the browsers in which it works fetch the intermediate cert from there; Firefox simply doesn't do that. It actually works in the latest release of Firefox, as well.
Here is a classic paper on the style and advantages of functional programming:
m l
u s.pdf
http://www.math.chalmers.se/~rjmh/Papers/whyfp.ht
Also, John Backus' Turing Aware lecture, "Can Programming Be Liberated from the Von Neumann Style?"
http://www.stanford.edu/class/cs242/readings/back
If you allow shell access, then of course such restrictions are ineffective, since people can install/use their own forwarders, as you did. To make them effective, you restrict the relevant accounts to port forwarding only.
There's a lot of exaggeration and vagueness on both sides of this little
tempest. What suffices for one enterprise may not for another, so it is
certainly silly for ssh.com to claim that OpenSSH is not
"enterprise-class" -- as Theo and others rightly point out, OpenSSH is
used successfully in many large contexts. On the other hand, it is a fact
that Tectia has a number of features OpenSSH lacks, some of which are
particularly relevant to large organizations (which is not the same as
simple widespread use). Here are a few of them:
* PKI support
Tectia can use X.509 certificates for both client and server
authentication. To add a new SSH server or change an existing one's host
key, all you need do is issue a certificate for it. Clients need only
have a copy of a single public key: the issuing CA certificate. No
constantly shifting mess of per-user and per-host known-host files to try
to keep in sync, no spurious "unknown host" or "host key changed messages"
confusing users and teaching them to ignore security warnings. It just
works.
For client authentication, there are no burgeoning copies of
authorized_keys files lying around, unmanaged, needing to be individually
tracked down whenever you want to turn off someone's access: instead, you
can simply revoke the user's certificate. And flexible rules can grant
access based on certificate attributes, like "anyone in the Foo Department
can log into this host."
The distributed-trust problem has been addressed abstractly by systems
like PKI and Kerberos. In a large (or even medium) scale environment, you
want to tie applications such as SSH into these systems, not have each one
use its own ad-hoc mechanism.
Note that both OpenSSH and Tectia support Kerberos. There is some
variation in how well they use it to address the above problems, though,
and I won't get into that here.
* Greater configuration flexibility
With the Tectia SSH server you can:
+ Modify almost all server parameters based on the client hostname and
address, or properties of the requested account (username and group
membership). Thus you can arrange that, accounts in one group permit
password authentication, while those in another group require
public-key -- or that connections coming from your internal network
allow a wide range of ciphers, while those coming from the outside
require a smaller, stronger set. You can accomplish some of this type
of thing with OpenSSH, but generally you have to run multiple
instances of the server on different ports.
+ Exert finer-grained control over what kinds of SSH services you
provide. You can forbid terminal access while still allowing sftp,
for example, by simply rejecting the corresponding SSH protocol
requests (shell and exec channels), rather than resorting to custom
shells or other hacks that have unwanted side effects.
+ Control port forwarding with ACLs that include permit/deny statements
and patterns matching user, target hostname, IP address, etc.
+ Require multiple forms of authentication for access (e.g. password and
public-key).
* SOCKS support for outgoing SSH connections (note this is different from
the OpenSSH -D feature, which Tectia has also).
* "chroot"-ed logins
* integrated support for RADIUS authentication
* Support for Windows-native Kerberos. Although OpenSSH can be built with
Kerberos support on Windows (with Cygwin), it does not
Some of my favorites:
"Topics in Algebra" by Herstein
"Topology" by Hocking and Young [Dover]
"Counterexamples in Topology" by Steen & Seebach [Dover]
"A Mathematical Introduction to Logic" by Enderton
"Galois Theory" by Stewart
Kerberos isn't designed for the Internet. You need to set it up explicitly for each trust domain on each client computer. So users can't just pull out their personal laptops and use them to log in...
/etc/krb5.keytab). A Kerberos client can run anywhere and does not require a prior host connection with the realm at all. You *can*, in fact, do exactly what you describe here as impossible: connect your laptop to a network and type "kinit user@REALM" to get credentials, then use a kerberized application such as OpenSSH. The Kerberos software can find a KDC for "REALM" from the DNS (assuming the appropriate rr's are available). Note that this is secure despite the insecurity of the DNS in general, since Kerberos is a shared-secret system: since you share a secret with the KDC (essentially your password), you can validate the KDC's response.
I'm afraid your entire point here is just technically false. Kerberos only requires host setup with if the host is a server; that is, to run a kerberized service on it, you need to establish a shared key for the service principal with the Kerberos system (KDC) and store it on the host where the corresponding server can find it (e.g.
One side job that doesn't have the problem of clashing with office hours is writing. Over the past few years, I have co-authored two O'Reilly books: "SSH, The Secure Shell (The Definitive Guide)" and "The Linux Security Cookbook." In addition to a substantial second income, I have had several follow-on writing and consulting opportunities (white papers, articles, etc.). Of course, there's the question of whether you want to spend even more time sitting in front of a computer in your off hours...
"editer"... "flush out"...
Perhaps you should subcontract out the editing part.
Q: What's purple and commutes?
A: An Abelian grape.
shouldn't decisions based on taxpayer money usually be based on cost analysis?
m l
They should be based on sound analysis, surely, but cost is only one component. There are plenty of other extremely good reasons to prefer -- indeed, to demand -- open source in government. The following letter, purportedly from a Peruvian official to a MS exec, lays them out very well:
http://www.theregister.co.uk/content/4/25157.ht
... in which he reflects on their founding slogan of 'Tech News First' and their commitment to that going forward... Thoughts or opinions, anyone?"
I really hate that bit of idiotic business-speak, "going forward." We should all feel incentivized to leverage our existing linguistic infrastructure, and architect a solution using existing word-assets rather than repurposing them -- going forward.
This is a shortsighted and ultimately ineffective approach to security.
To point out one simple problem: when you mention "SMTPS," you are apparently thinking of SMTP over SSL on the alternate port 465. But this method of securing SMTP (and other protocols) is deprecated by RFC 2595, section 7, in favor of STARTTLS (and similar mechanisms). Requiring people to use a VPN to do such a simple thing as submit authenticated mail to a remote server is overly complicated, burdensome, and inappropriate.
More generally, over time this approach simply won't result in better security, and you will have extra annoyance, complexity, and breakage with no upside. As long as you can exchange arbitrary bits between two hosts, in some way, there's a channel that can be multiplexed to do anything you like, and get around any exterior restriction. At first, this may result in some advantages, since only a small number of techies will know how to get around it. However, it is self-defeating. If it results in any significant inconvenience, a workaround will be codified into common software, and the restriction will shortly become meaningless. HTTP is a perfect example. Years ago, firewalls appeared which blocked all inbound TCP ports except HTTP -- the rationale being, HTTP is relatively harmless, most all it does is ask to see some files; configure the web server and file security properly, and what's to worry?
Of course, then distributed computing models became more widespread, and people wanted to do things like send information as well as receive it, do RPC, etc. -- but the only port vendors could be sure would be open was 80. So they turned on PUT and invented things like DCOM and SOAP -- and now port 80 is just as dangerous to have open as if we had these various things on their own ports and had them all open; there is no difference.
This process will just repeat itself. Security is not gained by blocking packets based on crude, low-level indicators like TCP port numbers. All you get is the same security problems you had before, only now with a network that is overly complex, difficult to use, and prone to breakage, because of all the random restrictions in place (unnecessary NAT, simplistic firewalls, etc.).
One of the more irritating tactics of posters with nothing to say is to attack a statement based on an interpretation they know to be wrong. It's like the Spelling Police
You insinuate that I know my interpretation of the situation to be "wrong," but you have no credible personal basis on which to make that claim (since you are posting anonymously), and present no facts to back it up. Your post is hence without merit. As for what this could possibly have to do with correcting spelling, that's anyone's guess, but it doesn't seem very interesting...
value of the theft is to be determined but that there was theft is almost
certain...
One of the more irritating tactics in the war of misinformation about IP
being waged by organizations like SCO, the RIAA, etc., is the intentional
misuse of language. Things like trying to make "filesharing" a dirty word
in itself, when in fact there is of course nothing more immoral about
copying files than there is about using a photocopier -- it depends on
what you're copying and what you're doing with it.
Another example is the rampant incorrect use of the terms "theft,"
"stealing," etc., intended to make the alleged perpetrators sound like
sordid, common criminals. Copying a file, no matter what the IP issues
surrounding it, is simply not "theft." From Webster's
dictionary:
Copying data does not deprive the owner of the original of that data. It
has not been removed, and he still has access to it and use of it. There
might be copyright infringement, and there might not be, but it is
not theft.
Five Golden Rules: Great Theories Of 20th-Century Mathematics -- And Why
They Matter (John L. Casti)
It Must Be Beautiful: Great Equations Of Modern Science
(collection of essays, edited by Graham Farmelo)
Mathematics: The Science Of Patterns
(Keith Devlin)
Beyond the Third Dimension: Geometry, Computer Graphics, and Higher Dimensions
(Thomas F. Banchoff)
It's hard to believe this is an issue in the year 2003. We've had good device-, resolution-independent graphics systems for decades (e.g. Display PostScript, NeWS, etc.). It is an obviously, profoundly stupid thing to do to measure anything for display, at a high level, in units tied to something as hardware-dependent as pixels. And yet, here we are, discussing this problem as if it were some kind of deep technical issue -- and people are afraid to buy better monitors because they have to squint at them, because the software running the displays of the major OS's still makes mistakes we learned how to avoid in the 70's.
Our species is doomed.
a nice Linksys router.
Open only the ports you need and make sure the software running on them is secure.
This is a naive and misleading suggestion. First, you cannot "make sure" any software is "secure." Second, this does not address the myriad vulnerabilities inherent in the software people run every day which are not network servers: mail readers vulnerable to viruses, web browsers vulnerable to many kinds of malicious content, etc. For both these reasons and more, security must be a multi-level, ongoing process -- not just "set up a firewall and you're secure!"
Another way to do that is to use RFC - Remote Filesystem Checker (look it up on freshmeat) which scp's a static binary of your IDS of choise to the machine that needs checking, runs it, and compares with the local DB of the 'trusted' machine. Much cheaper than buying specialized hardware.
Much cheaper, and not at all the same thing. This is not equivalent, which is made clear in the sequence of examples in the book of which this is an excerpt. "Copying over a static binary" does not guarantee it will do what you want, since if it's hacked the machine in question may have had its kernel or program loader altered so that the "binary" does not do what you think it will. Or the tool you use to "copy [it] over" may have been altered, or the network traffic involved in comparing the local and remote signatures may be compromised. Etc. You may consider these unlikely attacks, and I agree, but they are possible, and this recipe is at the higher end of paranoia attempting to address these possibilities.
Of course, if the running kernel has been altered without changing any disk files, then you've really got a problem...
... sidestep typically insideous a provision...
... sidestep a typically insidious provision...
Um, how about:
OK, this is absurd. Judging by the general arrogance level, poeple who post to Slashdot obviously think of themselves as pretty smart. It's not very convincing, when the editing, spelling, grammar, etc. in the posts is so consistently bad! And do the Slashdot folks really think their publication can be taken seriously, when it's apparently edited by a bunch of not-very-well-educated 6th-graders? Wake up.
Maybe that in a forum mostly used by men, we have a total and absolute disgust of other men who suck another man's dick or to fuck another man in the ass.
Maybe you do, but then you've got some kind of weird hangup. I think it's more likely that "we" have disgust for people who think like you... fortunately though, your brand of intolerance is fading away.
or is that something that distinguishes a real nerd from the avergae joe computer user: the ability to withstand prolongued exposure to CRTs...
Or perhaps, merely the stupidity required to subject oneself to same.
Success!
To make a long story short -- I had to upgrade the BIOS. After that, the
nVidia board worked perfectly.
Thanks for all the input; without the assurance that these cards did
actually work in this setup, I would not have gone back and done the extra
testing/searching that turned up the solution.
inexpensive) card; however, I'm puzzled why I didn't work for me. As I
said, I did try the Xtasy nVidia GeForce4 Ti. I got no picture at all,
ever -- just single glimpse of a blinking cursor at power-on, which
immediately disappeared, then a blank screen. I also got this response
from VisionTek support (the card maker):
this. Are you using AGP or PCI?
I know about the monitor control issue, but since I have a Mac connected
also, this isn't a problem...
As is perfectly obvious from my post, I already have this converter, otherwise I couldn't be driving the display with my TiBook.