You know, forget the "voices from the hellmouth" crap. There should be a collection of "stupid things people say on slashdot." I'd buy it in a heartbeat -- hell, its one of the two reasons I read blogs anyhow.
(The other reason, of course, is that perhaps one in 50,000 posts is a gem -- something I am actually glad I read. (Fortunately, I haven't read the decent post yet for the month. I'm hoping for the good one before Christmas. (I realize statistics doesn't work this way. (Duh)))).
The certificate is optional for the server side, too. Most popular clients will carp at you if the key isn't signed, or if they don't recognize the signer, but its certainly not required by anything.
It comes from the fact that SSH is not signed by a certificate authority, and as such you cannot trust the server on the other end.
You most certainly do not need a certificate authority to trust the server on the other end. And for this article to imply that somehow SSH v2 is a solution is downright wrong.
If you're using SSH (either v1 or v2) to communicate with a server, and you want to avoid the man-in-the-middle attact described by the article, then you must be certain you're talking to to the server, and not to the man in the middle. The only way to do this is to be certain that the public key that you have for the server you want to talk to really is the public key for the server you want to talk to.
There are several ways to do this:
You can copy the public key from the server using some secure method, such as copying it onto a floppy and transfering it to your machine using sneaker net, or transfering it through encrypted email
You can copy the public key across the (possibly insecure) network, and verify that the key was not replaced in transit by verifying the key signature by some secure means (perhaps by getting on the telephone with an administrator of the other machine)
Although I don't believe SSH directly supports it (someone will hopefully correct me if I'm wrong), the public key can be signed by some trusted third party. If you trust the thrid party, you can trust the key.
or, you can simply allow SSH to transfer the public key across the insecure network, and when it asks "should I trust this key", you can simply answer "yes".
This last method, of course, is the only method that is vulnerable to the man in the middle attack described in the article. Unfortunatly, its also the default method used by most SSH users. Obviously, there are several ways to reliably transfer the public keys without using a signature by a certificate authority.
It also can not be emphasised enough that a generic "certificate authority" by itself should not be considered a guarantee that you're talking to who you think you're talking to. Getting a signed certificate from a company like Verisign is not an insurmountable problem. Verisign is certainly reliable enough to trust with something like your credit card numbers -- credit card numbers are relatively inexpensive to replace if they're stolen, and stealing credit card numbers is painfully simple through many means much simpler than attacking Verisign. But I certainly wouldn't trust it for anything really important, unless I had absolutely no choice.
If you're using SSH (v1 or v2), or setting up a vpn, and you want to be reasonably certain you're not talking to a man in the middle, then nothing can replace coping the public key from machine in a known secure and reliable method. And if your client ever says "the signature of the server has changed. connect anyway (y/n)?" be very, very, very certain you know exactly what you're doing before you hit "y".
I apologize for my tone. And I also apologize for my conclusion... I'm reading a lot of posts on here saying "SSL is secure because it uses a CA, and SSH is not secure because it does not use a CA." Apparently, the exact function of a CA isn't generally well known; if the attitude of posters on slashdot is any indication, there are quite a few people who believe CA's provide some type of "magic" security.
I agree that the way CA's are generally used today, where often the only existing CA (VeriSign) is alone used in some kind of binary "trust/not trust" is almost insane. And for most of the traffic SSH is used for, methods of exchange are usually possible that are orders of magnitude more secure than trusting Verisign.
But for one of the most common types of encrypted traffic -- transmitting mostly non-sensitive information to e-commerce sites -- I think CA's are a fairly reasonable solution. If someone decides to steal my credit card numbers, Verisign is not the weak link. Getting on the phone to call a (potentially unreliable or corrupt) representitive of amazon.com to verify their server id is not likely to measurably improve the security of the transaction, and is almost certain not prevent me from losing anything of value (since my credit card numbers aren't worth that much to me anyhow -- I'd lose some time, but not money, if they were stolen, but I'd probably lose more time if I called every e-commerce site to verify the server id before placing an order). As long as people understand what the CA's are capable of doing, and what they're not capable of doing, I have no problem with them. It does seem that many people are confused about their capabilities, though.
This is a good thing and SSH's handling of the situation is more secure than a central signing authority.
black is white. stop is go. SSH's handling of the situation is most certainly not more secure than a central signing authority.
he'd rather that we trust some other person with our security.
Look, the article was a tripey piece of crap, but it certainly never said that. The simple, basic fact that the article gave was this -- if you don't verify who you're talking to, then you haven't verified who you're talking to. Somehow, this dumbass managed to make an entire article out of that. And I read it, and got the ad impressions, and everything. I feel dirty.
For anyone who hasn't taken the time to read the article yet, or ever learn basic security stuff, let me boil it down: In every single system known to man or mathematics, to identify an entity X, you must trust something to say "method Y is an accurate method to identify X". Unfortunately, the default way to get get that identification method in SSH and SSL is fundementally flawed. If entity W has no way to identify X, but wants to talk to X for the very first time, W simply asks X "what is a question that only you can answer correctly, and by answering proves that you are X?" That leads to a false sense of security at best, because entity Z can step in front of X, and provide a false answer to the "how can I identify you?" question. Voila! Now, W is talking to Z, and since Z was presumably smart enough to supply a question it can answer, W will never know that its speaking to Z instead of X.
Most two year olds could come up with a half dozen solutions for this problem. Certificate Authorities (where, essentially, someone pays a third party to certify that the identification question is a valid one) are certainly one partial solution. Manually transmitting the identification question (usually in the form of public keys) on secure medium is another. Ignoring the problem, because its inconvenient to deal with, is another solution.
As many people have pointed out already, ignoring the problem is often the "good enough" thing to do anyhow, since intercepting SSH or SSL communications is still several orders of magnitude more difficult than other attack vectors. But saying a Certificate Authority is bad because you can be lulled into a false sense of security is kind of like saying "you should only do electrical work on your house with the power switched on, since switching the power off lulls you into a false sense of security." You're certainly still vulnerable to attacks to the Certificate Authority, in exactly the same way you can still be electrocuted even if you think the fuse box is off. But there are certainly many situations where the CA's are the least inexpensive and effective method to mitigate the most risk.
I don't think any of these should change the key, unless you have a really lazy administrator. The private key is generally set up to be readable only by root. Presumably, the root user can copy it to a new machine at will.
RMS talks about a number of different licenses here. He breaks up each license on a number of axis -- their compatibility with the GPL, whether or not they are copyleft (viral, in the rough vernacular we're so fond of here), and whether or not they are free.
He adds a small amount of his own editorializing; however, he limits his comments primarily to the free / not free axis of each license, the onerous and difficult clauses in other licenses, and the legal looseness of some licenses. He refrains from making any value judgement on the non-copyleft nature of the BSD-type license, so most of you can probably read the entire page without getting your underwear in a bunch.
It's fun to bash RMS, but he at least understands the issues, unlike the guy that wrote that wrote that article in webtechniques. Why did slashdot post this article in the first place?
Does my door's lock really stand up at all? Is tacking a lock on your front door a way to protect it? Shouldn't you really put a door with a lock on the front of your house?
This area brings a lot of ambiguity. What is the legitmacy of locks on a global level?
Its seems that while the lock is well built, and appears sound, locks depend a lot on the good faith on the part of the people using the door.
Dude, either you're a troll, or your precious Professor Zoller is a troll.
Come on, dude... nuclear hand grenades? Some type of special security clearance that allows him to talk to any random person, but not to members of the press? He was investigated by some random MPs from the local military base, instead of guys in bad suits from the FBI? His work in "discovering" the fallout from Chernobyl? Radioactive fish in Seattle that the EPA is "forbidden" to talk about?
Also, your view of Russians is more than a little xenophobic. Here's a clue -- they're human beings, just like you, motivated by the same thoughts, dreams, and desires you and other people you know are motivated by. The firefighters involved could not have been happy about their jobs, but to say that they were "forced by the KGB" implies that they somehow had different motivations than american soldiers who died in Iraq, or american firejumpers who die fighting forest fires, or american coal miners who die of black lung disease. These are human beings who died, not mindless automatons with "not exactly a concern for human life" (your exact words).
Perhaps, in the future, you should try to remember two things: first, even college professors are human, motivated by human needs and desires, and those motivations are not always rational or honest; second, even russians are human, motivated by human needs and desires, and sometimes those motivations are rational and honest.
Actually, just remember that it applies to everyone.
However, it is a lawyer's job to argue on behalf of his or her client, regardless of what he or she thinks about that client. I think that this is a rather bad way for things to be
I disagree strongly. I think its a very good way for things to be. However, I think there's a huge difference between "arguing on behalf of the client" and "arguing any half-baked legal crap the client pulled out of his ass."
The legal system is large, complicated, and scary. If you find yourself embroiled in it, you must have someone familiar with it working on your behalf, or you will be chewed, swallowed, and shat out, long before you know what happened.
But any law firm that hasn't politely but firmly explained to BT why this lawsuit is a very, very bad idea is most definately not working on the behalf of BT. They're working on the behalf of BT's checkbook. And there's a big difference, even for lawyers.
PC users are... more likely to go out on a romantic meal... Mac counterparts who would rather be at a dinner party.
PC users are 50% more likely to prefer romantic films than Mac users.
PC users... [are] three times more likely to spend more than £200 per month on their wardrobe.
you're more likely to find PC users out clubbing than Mac-sters
This generally matches my experience, too. All the PC people around here spend all their time trying to get laid, but end up doing everything but getting laid -- they dink around with clothes, and romantic dinners, and romantic movies, and clubs, and everything but the actual sex. They're generally not sure what they actually want, but they've managed to convince themselves that it must be really complicated to get it. Boy, are they a frustrated lot.
The Mac people, on the other hand, know what the want to do, and the best way to get it. They seem pretty happy.
The less said about the linux users, the better.
I don't see what changed?
on
Deja.com Vu!
·
· Score: 3
The only change I see is that www.dejanews.com once again redirects to the page www.deja.com. The usenet search otherwise looks exactly the same to me -- the same busted article threading, the same crufty featureless search engine, the same hobbled archive only going back about 17 months, the same totally broken "select language" non-feature.
Let's face it -- the usenet news part of deja has been neglected for a looong time now. Only time will show if this move reflects deja's renewed interest in being the best usenet news archive available, or if if its just a pit stop on the road to closing the doors and shutting the lights.
from a security point of view, someone who is only trying to use a service they already know you have isnt' scanning you; someone is scanning you to find something out they didn't already know, which is something you should be aware of
So... if I type http://www.monkey.com/ into the address bar of my web browser, just to see what comes up, I'm doing a "port scan" on that server? Should the administrator of www.monkey.com be aware that I'm trying to hack into the site?
If I decide I want to download the latest version of NetBSD, and I just randomly guess
$ ncftp ftp.netbsd.org
am I doing simething the administrator of the domain should be aware of? (In fact, last night I did exactly this. I had no idea where to download NetBSD -- that was just my first guess. I had no idea if there really was machine named ftp.netbsd.org, or what services it may provide. By trying to connect, I really was trying to discover something I didn't already know.)
The only thing I'd call a real "port scan" is the kind of thing you can do with a program like nmap -- scanning dozens or hundreds of ports at once, just to see which are open. It shouldn't be a suprise to anyone that those "port scans" are easy to log, but next to worthless to break into the machine.
I'm afraid I don't understand what people are calling a "port scan." If I type
$ telnet foo.bar.com 25
does it count as a port scan in your book? Because thats the exact equivilant of what anyone checking for mail relays is going to do -- there is no reason to check any port other than the mail port if you're looking for a mail relay. But, if you've got an MX record screwed up somewhere, you're going to get exactly the same thing if someone tries to send you mail. How do you distinguish between someone checking for mail relays, and someone trying to send you mail?
Another poster comments "how much of an "attack" is it to scan to see if FTP is open?" What kind of "scan" would anyone do to see if FTP is open? The user check to see if port 21 is open, and thats it.
I remember reading once on slashdot how an @Home nameserver was "port scanning" some guys machine, because it responded to his machine's DNS requests. Come on -- that's not a scan.
If checking one port is a "scan", then I'm afraid I probably scan hundreds, or even thousands, of machines a day. I'm such a 'leet hacker. Most of our webservers get tens of thousands of "scans" a day (generally, by people "scanning" port 80), from people all over the world. The mail servers get thousands of scans, too. What are you guys talking about?
A WYSIWYG typesetting program, as long as the programmers and users understand that you place frames on a page as opposed to inserting things into a text stream, will do a world of wonders for Linux.
We're arguing at cross purposes, I believe. I'm arguing that a WYSIWYG combination text editor/typesetter is going to devolve into a system where most users are going to write an input stream that creates the "correct looking" output. A combination text editor/typsetter is a very bad way to edit structured documents.
You're arguing that a WYSIWYG typesetter is a good way to format a well-structured documents into a good looking output. I'm inclined to agree.
But, the "frames" that you describe seems very useful for document typesetting, and useless for document editing. For example, I'm editing a document right now -- a response to you. How would "frames" allow me to add a layer of structure to this response?
We need a good cross platform technical text editor/type setter solution now.
Yeah. And we need a good cross platform graphics editor/web server, and a good cross platform video decoder/java compiler.
I do agree that we need a good cross platform type setter. And we need a good structured document editor. But I believe that any WYSIWYG text editor/typesetter is ultimately going to devolve into Microsoft Word.
If the package gives users the option of coding to presentation instead of semantics, then most users will code to presentation instead of semantics. This is fine if presentation is important. This is not fine if semantics are important. And in general, semantics are important in long technical documents that are going to be transformed to a number of different presentations.
(I'm tempted to defend TeX here -- I disagree with your criticisms of TeX, and I probably have a much higher opionion of it than you do. But, TeX is showing its age in a number of ways. Its probably reached the end of its useful life in many ways, and it deserves to be replaced.)
Your nameservers are sending packets to my computer, and I would like it to stop immediately.
I realize that ever "name" on the internet is associated with network "addresses". Further, I realize that nameservers are vitally important for mapping those names to network addresses, and that these addresses are fundemental to the operation of the internet. However, I would like your nameservers to communicate the network addresses of hosts on the internet without connecting to my machine across the network, or sending information directly to my machine in any way.
I would be much more comfortable if you would simply mail me the current network addresses for the hosts I wish to visit -- I've included 132 self-addressed, stamped envelopes for this purpose.
Nah... a portscan might just send an "ACK", too. In fact, a cracker could be sending just about anything, including bogus source IP addresses, even if its to do nothing more than figure out how your firewall is filtering out packets.
But if @Home is actually responsible for the packets, I can't imagine any reason they would do anything besides check to see if the port is open and unprotected, and the simplest way to do that is to try to set up a plain, vanilla connect() scan (beginning with a "SYN" packet, not an "ACK"). If anything as "clandestine" as unexpected bare "ACK" packets show up from random @Home hosts, I'd be suprised if @Home were actually responsible (unless they somehow hired an incompetent script kiddy as a sys admin, which might not be that suprising).
I'm also inclined to believe the nameservers are not portscanning you. Here's a brief (and incomplete) explanation of how a nameserver works.
When your computer wants to look up an address using DNS, it will send a UDP "question" packet from some "high" port to port 53 of the nameserver. Then, after doing some magic to determine the address, the nameserver sends back a UDP "response" packet to the high port on your computer it got the question from.
So, if you're getting a UDP packet from port 53 of a nameserver to a high numbered port on your machine, it generally means that either: 1) you sent a "question" packet to the nameserver, and it is politely responding to you, or 2) someone else sent a bogus "question" packet to the nameserver, but managed to spoof your IP instead of their own into the header of the packet, and the nameserver is politely responding to you, or 3) someone else is sending a bogus "response" packet to you, but managed to spoof the nameserver's IP instead of their own into the header of packet.
There are probably a number of ways #2 (reply's to a question you didn't ask) could occur, ranging from normal network entropy, to some random dude mistakenly misconfiguring his machine, to some eleet hacker d00d sending out bogus "question" packets to the name server intentionally. With some imagination, I can construct scenarios where both #2 (spoofing the origin of the question) and #3 (spoofing the origin of the reply) might be beneficial to a hacker, but not in hacking your box. My imagination is fairly limited, though.
To answer your more specific questions:
It is possible to send a packet to one IP of a multi-ip machine, and get a packet back from another IP of the same machine. This might trip your firewall. If "shouldn't" happen with a DNS server, but "shouldn't" and "can't" are two entirely different words.
If you want to find the format of a DNS packet, check RFC 1034 and RFC 1035. The biggest tip off that you're looking at a DNS packet should be that it originates from port 53 on the nameserver.
I would be very, very reluctant to say that "10 ports in a 20 port (high) range" indicate a port scan -- generally, people who really want to root your machine will only try a small handful of (low) ports corresponding to vulnerable services, and leave the rest untouched.
If you're seeing only a single "ACK" TCP packet, then someone sending out packets while poking into their TCP stack at a level deep enough that you shouldn't trust ANYTHING contained in that packet -- definately not the IP address, and perhaps not even the MAC address. If someone is on the same wire as you, then it is possible they could be sending out a series of packets with spoofed originating IP, and just passively sniffing on the wire to see how your machine is responding. (I don't know enough about cable modems to know how hackable the networks are, though.) If this is the case, the @Home nameservers have nothing to do with these packets.
But I'm inclined to believe that these packets are nothing more than standard DNS packets, possibly being returned from the "wrong" IP of a multi-ip'd nameserver. You probably have nothing to worry about.
You're correct, of course -- there are more record stores in Fargo than that. We also have a movie theatre that might show an NC-17 movie every now and again, too. But the situation is not as rosy as you paint. You really don't find NC-17 or unrated movies at Blockbuster or at the local theatre chain. You're really not going to find an uncut Eminem or Bloodhound gang album at Target or Wal-Mart.
People who reluctantly agree with "voluntary labeling" are often very, very suprised what type of crap actually ends up getting labled. They're also very suprised when that labled stuff really does become difficult to find. Everyone thinks "voluntary labeling won't be so bad. They'll only label the really nasty bad stuff. They won't go overboard and label anything remotely offensive." Then, they're suprised when a movies Crash or Eyes Wide Cut gets "bad" labels stuck on.
Then, they think "well, the label is there to warn parents. Major content distributors won't start indiscriminantly filtering out anything with a label. Thats not what the labels are for!" Then, they're suprised when providers like Blockbuster and WalMart and the major theatre chains put a block on anything with the label.
If you don't think the same thing would happen with.xxx sites, you haven't been paying attention. A lot of site we would never consider porn will be labled.xxx, and a lot of major carriers will block those sites. It will happen just like it happened with "voluntary" X and NC-17 ratings on movies, and with Tipper Gore's "voluntary" record labels. And people will be suprised.
I agree -- there should definately be.xxx, and it should be strictly enforced through the force of law. And any site that habitually links to pornographic material should be forced into that domain, so that we wouldn't have to see it.
For example, one website that should be prevented from finding its way into any clean, god fearing home is this one -- you would not believe some of the filth and perversion that is constantly being linked to from that site.
And I know that all of the hard-core anti-porn crusaders would agree with me on this, too -- I look forward to the day when viewing evil, bad, rotten sites is difficult, in exactly the same way listening to evil, bad, rotten songs, or watching evil, bad, rotten movies is getting difficult up here in Fargo, ND.
I look forward to the day when ISP's are all large, scared multi-national corporations, filtering content based on almost arbitrary labels. It works so well with the only "record stores" left around here (like Wal-mart and Target), and it works so well with the homogonized movie theatre chains, too. I feel so cacooned and protected, knowing I'll never see an NC-17 movie or buy an uncensored BloodHound gang song again. I will be even safer when I couldn't view bad websites even if I wanted to.
And I know that my definition of "bad" will be the same as yours. It just has to be! I know exactly what you shouldn't be seeing or listening too!
Slashdot Mirror
Hell... why not just smuggle furbies?
By the way, a decent GC requires a VM
You know, forget the "voices from the hellmouth" crap. There should be a collection of "stupid things people say on slashdot." I'd buy it in a heartbeat -- hell, its one of the two reasons I read blogs anyhow.
(The other reason, of course, is that perhaps one in 50,000 posts is a gem -- something I am actually glad I read. (Fortunately, I haven't read the decent post yet for the month. I'm hoping for the good one before Christmas. (I realize statistics doesn't work this way. (Duh)))).
The certificate is optional for the server side, too. Most popular clients will carp at you if the key isn't signed, or if they don't recognize the signer, but its certainly not required by anything.
You most certainly do not need a certificate authority to trust the server on the other end. And for this article to imply that somehow SSH v2 is a solution is downright wrong.
If you're using SSH (either v1 or v2) to communicate with a server, and you want to avoid the man-in-the-middle attact described by the article, then you must be certain you're talking to to the server, and not to the man in the middle. The only way to do this is to be certain that the public key that you have for the server you want to talk to really is the public key for the server you want to talk to.
There are several ways to do this:
- You can copy the public key from the server using some secure method, such as copying it onto a floppy and transfering it to your machine using sneaker net, or transfering it through encrypted email
- You can copy the public key across the (possibly insecure) network, and verify that the key was not replaced in transit by verifying the key signature by some secure means (perhaps by getting on the telephone with an administrator of the other machine)
- Although I don't believe SSH directly supports it (someone will hopefully correct me if I'm wrong), the public key can be signed by some trusted third party. If you trust the thrid party, you can trust the key.
- or, you can simply allow SSH to transfer the public key across the insecure network, and when it asks "should I trust this key", you can simply answer "yes".
This last method, of course, is the only method that is vulnerable to the man in the middle attack described in the article. Unfortunatly, its also the default method used by most SSH users. Obviously, there are several ways to reliably transfer the public keys without using a signature by a certificate authority.It also can not be emphasised enough that a generic "certificate authority" by itself should not be considered a guarantee that you're talking to who you think you're talking to. Getting a signed certificate from a company like Verisign is not an insurmountable problem. Verisign is certainly reliable enough to trust with something like your credit card numbers -- credit card numbers are relatively inexpensive to replace if they're stolen, and stealing credit card numbers is painfully simple through many means much simpler than attacking Verisign. But I certainly wouldn't trust it for anything really important, unless I had absolutely no choice.
If you're using SSH (v1 or v2), or setting up a vpn, and you want to be reasonably certain you're not talking to a man in the middle, then nothing can replace coping the public key from machine in a known secure and reliable method. And if your client ever says "the signature of the server has changed. connect anyway (y/n)?" be very, very, very certain you know exactly what you're doing before you hit "y".
I apologize for my tone. And I also apologize for my conclusion... I'm reading a lot of posts on here saying "SSL is secure because it uses a CA, and SSH is not secure because it does not use a CA." Apparently, the exact function of a CA isn't generally well known; if the attitude of posters on slashdot is any indication, there are quite a few people who believe CA's provide some type of "magic" security.
I agree that the way CA's are generally used today, where often the only existing CA (VeriSign) is alone used in some kind of binary "trust/not trust" is almost insane. And for most of the traffic SSH is used for, methods of exchange are usually possible that are orders of magnitude more secure than trusting Verisign.
But for one of the most common types of encrypted traffic -- transmitting mostly non-sensitive information to e-commerce sites -- I think CA's are a fairly reasonable solution. If someone decides to steal my credit card numbers, Verisign is not the weak link. Getting on the phone to call a (potentially unreliable or corrupt) representitive of amazon.com to verify their server id is not likely to measurably improve the security of the transaction, and is almost certain not prevent me from losing anything of value (since my credit card numbers aren't worth that much to me anyhow -- I'd lose some time, but not money, if they were stolen, but I'd probably lose more time if I called every e-commerce site to verify the server id before placing an order). As long as people understand what the CA's are capable of doing, and what they're not capable of doing, I have no problem with them. It does seem that many people are confused about their capabilities, though.
This is a good thing and SSH's handling of the situation is more secure than a central signing authority.
black is white. stop is go. SSH's handling of the situation is most certainly not more secure than a central signing authority.
he'd rather that we trust some other person with our security.
Look, the article was a tripey piece of crap, but it certainly never said that. The simple, basic fact that the article gave was this -- if you don't verify who you're talking to, then you haven't verified who you're talking to. Somehow, this dumbass managed to make an entire article out of that. And I read it, and got the ad impressions, and everything. I feel dirty.
For anyone who hasn't taken the time to read the article yet, or ever learn basic security stuff, let me boil it down: In every single system known to man or mathematics, to identify an entity X, you must trust something to say "method Y is an accurate method to identify X". Unfortunately, the default way to get get that identification method in SSH and SSL is fundementally flawed. If entity W has no way to identify X, but wants to talk to X for the very first time, W simply asks X "what is a question that only you can answer correctly, and by answering proves that you are X?" That leads to a false sense of security at best, because entity Z can step in front of X, and provide a false answer to the "how can I identify you?" question. Voila! Now, W is talking to Z, and since Z was presumably smart enough to supply a question it can answer, W will never know that its speaking to Z instead of X.
Most two year olds could come up with a half dozen solutions for this problem. Certificate Authorities (where, essentially, someone pays a third party to certify that the identification question is a valid one) are certainly one partial solution. Manually transmitting the identification question (usually in the form of public keys) on secure medium is another. Ignoring the problem, because its inconvenient to deal with, is another solution.
As many people have pointed out already, ignoring the problem is often the "good enough" thing to do anyhow, since intercepting SSH or SSL communications is still several orders of magnitude more difficult than other attack vectors. But saying a Certificate Authority is bad because you can be lulled into a false sense of security is kind of like saying "you should only do electrical work on your house with the power switched on, since switching the power off lulls you into a false sense of security." You're certainly still vulnerable to attacks to the Certificate Authority, in exactly the same way you can still be electrocuted even if you think the fuse box is off. But there are certainly many situations where the CA's are the least inexpensive and effective method to mitigate the most risk.
because windoze boxen are inheritently insecure.
You're a stupid fucking troll, aren't you?
I don't think any of these should change the key, unless you have a really lazy administrator. The private key is generally set up to be readable only by root. Presumably, the root user can copy it to a new machine at will.
RMS talks about a number of different licenses here. He breaks up each license on a number of axis -- their compatibility with the GPL, whether or not they are copyleft (viral, in the rough vernacular we're so fond of here), and whether or not they are free.
He adds a small amount of his own editorializing; however, he limits his comments primarily to the free / not free axis of each license, the onerous and difficult clauses in other licenses, and the legal looseness of some licenses. He refrains from making any value judgement on the non-copyleft nature of the BSD-type license, so most of you can probably read the entire page without getting your underwear in a bunch.
It's fun to bash RMS, but he at least understands the issues, unlike the guy that wrote that wrote that article in webtechniques. Why did slashdot post this article in the first place?
Does my door's lock really stand up at all? Is tacking a lock on your front door a way to protect it? Shouldn't you really put a door with a lock on the front of your house?
This area brings a lot of ambiguity. What is the legitmacy of locks on a global level?
Its seems that while the lock is well built, and appears sound, locks depend a lot on the good faith on the part of the people using the door.
Dude, either you're a troll, or your precious Professor Zoller is a troll.
Come on, dude... nuclear hand grenades? Some type of special security clearance that allows him to talk to any random person, but not to members of the press? He was investigated by some random MPs from the local military base, instead of guys in bad suits from the FBI? His work in "discovering" the fallout from Chernobyl? Radioactive fish in Seattle that the EPA is "forbidden" to talk about?
Also, your view of Russians is more than a little xenophobic. Here's a clue -- they're human beings, just like you, motivated by the same thoughts, dreams, and desires you and other people you know are motivated by. The firefighters involved could not have been happy about their jobs, but to say that they were "forced by the KGB" implies that they somehow had different motivations than american soldiers who died in Iraq, or american firejumpers who die fighting forest fires, or american coal miners who die of black lung disease. These are human beings who died, not mindless automatons with "not exactly a concern for human life" (your exact words).
Perhaps, in the future, you should try to remember two things: first, even college professors are human, motivated by human needs and desires, and those motivations are not always rational or honest; second, even russians are human, motivated by human needs and desires, and sometimes those motivations are rational and honest.
Actually, just remember that it applies to everyone.
However, it is a lawyer's job to argue on behalf of his or her client, regardless of what he or she thinks about that client. I think that this is a rather bad way for things to be
I disagree strongly. I think its a very good way for things to be. However, I think there's a huge difference between "arguing on behalf of the client" and "arguing any half-baked legal crap the client pulled out of his ass."
The legal system is large, complicated, and scary. If you find yourself embroiled in it, you must have someone familiar with it working on your behalf, or you will be chewed, swallowed, and shat out, long before you know what happened.
But any law firm that hasn't politely but firmly explained to BT why this lawsuit is a very, very bad idea is most definately not working on the behalf of BT. They're working on the behalf of BT's checkbook. And there's a big difference, even for lawyers.
PC users are... more likely to go out on a romantic meal... Mac counterparts who would rather be at a dinner party.
... [are] three times more likely to spend more than £200 per month on their wardrobe.
PC users are 50% more likely to prefer romantic films than Mac users.
PC users
you're more likely to find PC users out clubbing than Mac-sters
This generally matches my experience, too. All the PC people around here spend all their time trying to get laid, but end up doing everything but getting laid -- they dink around with clothes, and romantic dinners, and romantic movies, and clubs, and everything but the actual sex. They're generally not sure what they actually want, but they've managed to convince themselves that it must be really complicated to get it. Boy, are they a frustrated lot.
The Mac people, on the other hand, know what the want to do, and the best way to get it. They seem pretty happy.
The less said about the linux users, the better.
The only change I see is that www.dejanews.com once again redirects to the page www.deja.com. The usenet search otherwise looks exactly the same to me -- the same busted article threading, the same crufty featureless search engine, the same hobbled archive only going back about 17 months, the same totally broken "select language" non-feature.
Let's face it -- the usenet news part of deja has been neglected for a looong time now. Only time will show if this move reflects deja's renewed interest in being the best usenet news archive available, or if if its just a pit stop on the road to closing the doors and shutting the lights.
Theo de Raadt is perhaps the most brilliant guy in the BSD world and I'd place him as one of the top 3 coders in the world.
So... you'd put put Theo on a level above Bill Joy? I'm having a real hard time with that.
So... if I type http://www.monkey.com/ into the address bar of my web browser, just to see what comes up, I'm doing a "port scan" on that server? Should the administrator of www.monkey.com be aware that I'm trying to hack into the site?
If I decide I want to download the latest version of NetBSD, and I just randomly guessam I doing simething the administrator of the domain should be aware of? (In fact, last night I did exactly this. I had no idea where to download NetBSD -- that was just my first guess. I had no idea if there really was machine named ftp.netbsd.org, or what services it may provide. By trying to connect, I really was trying to discover something I didn't already know.)
The only thing I'd call a real "port scan" is the kind of thing you can do with a program like nmap -- scanning dozens or hundreds of ports at once, just to see which are open. It shouldn't be a suprise to anyone that those "port scans" are easy to log, but next to worthless to break into the machine.
Another poster comments "how much of an "attack" is it to scan to see if FTP is open?" What kind of "scan" would anyone do to see if FTP is open? The user check to see if port 21 is open, and thats it.
I remember reading once on slashdot how an @Home nameserver was "port scanning" some guys machine, because it responded to his machine's DNS requests. Come on -- that's not a scan.
If checking one port is a "scan", then I'm afraid I probably scan hundreds, or even thousands, of machines a day. I'm such a 'leet hacker. Most of our webservers get tens of thousands of "scans" a day (generally, by people "scanning" port 80), from people all over the world. The mail servers get thousands of scans, too. What are you guys talking about?
A WYSIWYG typesetting program, as long as the programmers and users understand that you place frames on a page as opposed to inserting things into a text stream, will do a world of wonders for Linux.
We're arguing at cross purposes, I believe. I'm arguing that a WYSIWYG combination text editor/typesetter is going to devolve into a system where most users are going to write an input stream that creates the "correct looking" output. A combination text editor/typsetter is a very bad way to edit structured documents.
You're arguing that a WYSIWYG typesetter is a good way to format a well-structured documents into a good looking output. I'm inclined to agree.
But, the "frames" that you describe seems very useful for document typesetting, and useless for document editing. For example, I'm editing a document right now -- a response to you. How would "frames" allow me to add a layer of structure to this response?
We need a good cross platform technical text editor/type setter solution now.
Yeah. And we need a good cross platform graphics editor/web server, and a good cross platform video decoder/java compiler.
I do agree that we need a good cross platform type setter. And we need a good structured document editor. But I believe that any WYSIWYG text editor/typesetter is ultimately going to devolve into Microsoft Word.
If the package gives users the option of coding to presentation instead of semantics, then most users will code to presentation instead of semantics. This is fine if presentation is important. This is not fine if semantics are important. And in general, semantics are important in long technical documents that are going to be transformed to a number of different presentations.
(I'm tempted to defend TeX here -- I disagree with your criticisms of TeX, and I probably have a much higher opionion of it than you do. But, TeX is showing its age in a number of ways. Its probably reached the end of its useful life in many ways, and it deserves to be replaced.)
Nah... a portscan might just send an "ACK", too. In fact, a cracker could be sending just about anything, including bogus source IP addresses, even if its to do nothing more than figure out how your firewall is filtering out packets.
But if @Home is actually responsible for the packets, I can't imagine any reason they would do anything besides check to see if the port is open and unprotected, and the simplest way to do that is to try to set up a plain, vanilla connect() scan (beginning with a "SYN" packet, not an "ACK"). If anything as "clandestine" as unexpected bare "ACK" packets show up from random @Home hosts, I'd be suprised if @Home were actually responsible (unless they somehow hired an incompetent script kiddy as a sys admin, which might not be that suprising).
When your computer wants to look up an address using DNS, it will send a UDP "question" packet from some "high" port to port 53 of the nameserver. Then, after doing some magic to determine the address, the nameserver sends back a UDP "response" packet to the high port on your computer it got the question from.
So, if you're getting a UDP packet from port 53 of a nameserver to a high numbered port on your machine, it generally means that either: 1) you sent a "question" packet to the nameserver, and it is politely responding to you, or 2) someone else sent a bogus "question" packet to the nameserver, but managed to spoof your IP instead of their own into the header of the packet, and the nameserver is politely responding to you, or 3) someone else is sending a bogus "response" packet to you, but managed to spoof the nameserver's IP instead of their own into the header of packet.
There are probably a number of ways #2 (reply's to a question you didn't ask) could occur, ranging from normal network entropy, to some random dude mistakenly misconfiguring his machine, to some eleet hacker d00d sending out bogus "question" packets to the name server intentionally. With some imagination, I can construct scenarios where both #2 (spoofing the origin of the question) and #3 (spoofing the origin of the reply) might be beneficial to a hacker, but not in hacking your box. My imagination is fairly limited, though.
To answer your more specific questions:
But I'm inclined to believe that these packets are nothing more than standard DNS packets, possibly being returned from the "wrong" IP of a multi-ip'd nameserver. You probably have nothing to worry about.
You're correct, of course -- there are more record stores in Fargo than that. We also have a movie theatre that might show an NC-17 movie every now and again, too. But the situation is not as rosy as you paint. You really don't find NC-17 or unrated movies at Blockbuster or at the local theatre chain. You're really not going to find an uncut Eminem or Bloodhound gang album at Target or Wal-Mart.
.xxx sites, you haven't been paying attention. A lot of site we would never consider porn will be labled .xxx, and a lot of major carriers will block those sites. It will happen just like it happened with "voluntary" X and NC-17 ratings on movies, and with Tipper Gore's "voluntary" record labels. And people will be suprised.
People who reluctantly agree with "voluntary labeling" are often very, very suprised what type of crap actually ends up getting labled. They're also very suprised when that labled stuff really does become difficult to find. Everyone thinks "voluntary labeling won't be so bad. They'll only label the really nasty bad stuff. They won't go overboard and label anything remotely offensive." Then, they're suprised when a movies Crash or Eyes Wide Cut gets "bad" labels stuck on.
Then, they think "well, the label is there to warn parents. Major content distributors won't start indiscriminantly filtering out anything with a label. Thats not what the labels are for!" Then, they're suprised when providers like Blockbuster and WalMart and the major theatre chains put a block on anything with the label.
If you don't think the same thing would happen with
I agree -- there should definately be .xxx, and it should be strictly enforced through the force of law. And any site that habitually links to pornographic material should be forced into that domain, so that we wouldn't have to see it.
For example, one website that should be prevented from finding its way into any clean, god fearing home is this one -- you would not believe some of the filth and perversion that is constantly being linked to from that site.
And I know that all of the hard-core anti-porn crusaders would agree with me on this, too -- I look forward to the day when viewing evil, bad, rotten sites is difficult, in exactly the same way listening to evil, bad, rotten songs, or watching evil, bad, rotten movies is getting difficult up here in Fargo, ND.
I look forward to the day when ISP's are all large, scared multi-national corporations, filtering content based on almost arbitrary labels. It works so well with the only "record stores" left around here (like Wal-mart and Target), and it works so well with the homogonized movie theatre chains, too. I feel so cacooned and protected, knowing I'll never see an NC-17 movie or buy an uncensored BloodHound gang song again. I will be even safer when I couldn't view bad websites even if I wanted to.
And I know that my definition of "bad" will be the same as yours. It just has to be! I know exactly what you shouldn't be seeing or listening too!