I feel sorry for the folks putting this release together. They got handed a hot potato and it isn't clear how they are going to stabilize this distribution in time for the real release in a month. I installed the 64-bit version on two AMD machines (one laptop and one desktop) and both of them have issues with random lockups after 10 minutes or so. In addition nfs4 with autofs stopped working. Ironically default nfs4 was supposed to be one of the new features of this release. Last time this happened it was some weird nfs4 interaction with IPv6. I guess not even Red Hat is taking IPv6 seriously and making the developers eat their own dogfood.
In any case, I'll probably wait a while after the real release before I roll it out to the rest of the machines. It reminds me a bit of the old X11 releases where the word on the street was always to wait a month or two before installing it and let some other poor slob work out what is broken and how to work around it.
Blocking root is a bit of an over reaction. Blocking password, pam, kerberos, onetime and all that other rot is good enough for stopping the brute force attacks. Nobody is going to brute force root's 1k (or 2k) key in any usable timeframe. While one is editing the file, might as well put an ssh-level keepalive in there for 30 minutes to clean up dead connections and keep lame NAT boxes primed. Protocol 1 should probably also be turned off. It has a few known failure modes. Cranking down logingracetime keeps the bruteforce attacks from tying up too many resources. One should never see RSA login take 10 seconds on a modern system with the rsa key unlocked and stored in keyserver. Even typing the passowrd in realtime shouldn't take 10 seconds.
Protocol 2 LoginGraceTime 10 PermitRootLogin without-password PubkeyAuthentication yes PasswordAuthentication no ChallengeResponseAuthentication no KerberosAuthentication no GSSAPIAuthentication no UsePAM no X11Forwarding yes ClientAliveInterval 60 ClientAliveCountMax 30 AllowUsers root myaccount
Whatever happened to the claim that the ads paid for the hardcopy papers and the cover price was just a token fee to assure the advertisers that the papers weren't likely to just be taken and thrown out unread? If that is true, why would they need to charge anything in order to deliver the paper electronically? Don't the ads more than cover the delivery costs?
Nothing gets fixed until it breaks so fully that people can't ignore it any longer. ARIN should just hand out the last of their IP assignment already and then we can move on with actually deploying IPv6.
Luckily the MS users that are moving to Linux right now are the smarter / more inquisitive members of the MS crowd. It isn't too hard for the Linux community to support and assimilate them. Lets hope there isn't a large rush of the unwashed masses to Linux. It will be like "Eternal September" all over again.
WPA2 passwords can be either 0-63 character strings which will be converted to a 64-character hex key by the software, or can be specified as a 64-character hex key directly. Since the keyspace to guess a 64-character hex key is 2^256 choices long, the attacker is going to spend a very, very long time trying to guess the password.
My recommendation has always been that people that want the ultimate security use random keys pulled from/dev/random and converted to a hexadecimal number. That key should then be input using the hex key option. While they are at it, they should also turn off WEP and WPA1, turn off TKIP and only allow WPA2 with CCMP. That will give the crackers something hard to chew on.
The best reason for them to do other OS's is that it forces them to do a better job of dividing the program into OS-dependent and OS-independent parts. The longer they wait, the harder it will be to unravel things.
I'm not about to pay some 2x 15 cents so that the phone company can shuttle one under 256 byte message to my sweetie. What we did was get a pair of Google HTC G-1 phones and we use the IM app to "text". Not only is it faster, but there is no additional cost to sending each message. The transport (at least for google-talk, which is what we use) is your basic IP, which is billed at a flat rate of ~$25/mo.
Same here. This is the point I stopped reading too. Anybody that thinks that a PC takes 89 watts per hour isn't worth listening to for technical advice. The next line just cemented it for me "If it's left on overnight for 16 hours, it consumes 1.42kW." Aaarrrrg. How did our basic science education go so wrong??? Please tell me that this guy is really a movie reviewer that is sitting in for the technical person as they take the holidays off.
Maybe they don't want the more affluent citizens (and government officials) tracked by every terrorist network capable of bribing a cell phone technician?
There is no telling what capabilities the CALEA / E911 subroutines in the cell phones provide, but one thing is clear, if the positional information is available to the cell phone operators, it will be used by organised crime and terrorists looking to target specific people.
Who cares what ISP's do? If anyone cared they could run their own dns server and get all the protection they wanted.
The problem is the lard-asses running the top-level domains. All but a very small handful refuse to sign the zones they are entrusted with. If you want to pass a law to light a fire under someone, that is the group of operators you need to target.
I wish the message would have said something along the lines of "The Signing Authority that signed this certificate is unknown. This means that the name associated with this certificate may not be correct. The encryption and securing of your data as it travels across the net is not compromised in any way. Feel free to use this certificate to secure your data, just don't trust the name."
I'm surprised that more folks here aren't running their own resolvers. It isn't that hard, especially if you don't need to act as an authoritative server for serving your own domains and just need a recursive resolver. One nice hack you can configure if you run your own resolver is dnssec - cryptographically secured dns lookup. While there aren't many dns zones that are cryptographically signed yet, there are a little over 10,000 (see http://secspider.cs.ucla.edu/ ).
That is a start. Unless people start using dnssec and demanding that their websites be in secured dns zones, companies won't be bother to do the work needed to configure their dns zones with dnssec.
A pdf with simple instructions for setting up dnssec can be found here. I set up my domains and resolvers this way, and it only took an afternoon to get acquainted enough with the concepts to bumble through the instructions. I've been running it for a few days now and it seems to be working just fine.
http://www.isc.org/sw/bind/docs/DNSSEC_in_6_minutes.pdf
Slashdot Mirror
I feel sorry for the folks putting this release together. They got handed a hot potato and it isn't clear how they are going to stabilize this distribution in time for the real release in a month. I installed the 64-bit version on two AMD machines (one laptop and one desktop) and both of them have issues with random lockups after 10 minutes or so. In addition nfs4 with autofs stopped working. Ironically default nfs4 was supposed to be one of the new features of this release. Last time this happened it was some weird nfs4 interaction with IPv6. I guess not even Red Hat is taking IPv6 seriously and making the developers eat their own dogfood.
In any case, I'll probably wait a while after the real release before I roll it out to the rest of the machines. It reminds me a bit of the old X11 releases where the word on the street was always to wait a month or two before installing it and let some other poor slob work out what is broken and how to work around it.
Blocking root is a bit of an over reaction. Blocking password, pam, kerberos, onetime and all that other rot is good enough for stopping the brute force attacks. Nobody is going to brute force root's 1k (or 2k) key in any usable timeframe. While one is editing the file, might as well put an ssh-level keepalive in there for 30 minutes to clean up dead connections and keep lame NAT boxes primed. Protocol 1 should probably also be turned off. It has a few known failure modes. Cranking down logingracetime keeps the bruteforce attacks from tying up too many resources. One should never see RSA login take 10 seconds on a modern system with the rsa key unlocked and stored in keyserver. Even typing the passowrd in realtime shouldn't take 10 seconds.
Protocol 2
LoginGraceTime 10
PermitRootLogin without-password
PubkeyAuthentication yes
PasswordAuthentication no
ChallengeResponseAuthentication no
KerberosAuthentication no
GSSAPIAuthentication no
UsePAM no
X11Forwarding yes
ClientAliveInterval 60
ClientAliveCountMax 30
AllowUsers root myaccount
Give them a couple of years and the digital ballot stuffing software will get better. The voter numbers should be waaaay up.
Whatever happened to the claim that the ads paid for the hardcopy papers and the cover price was just a token fee to assure the advertisers that the papers weren't likely to just be taken and thrown out unread? If that is true, why would they need to charge anything in order to deliver the paper electronically? Don't the ads more than cover the delivery costs?
If you are truly using IPv6 couldn't you just plug a plain old Ethernet switch into your cable modem or dsl modem?
(Well, I guess that assumes one is running an OS that has a firewall just as capable as the ones in home "routers".)
Nothing gets fixed until it breaks so fully that people can't ignore it any longer. ARIN should just hand out the last of their IP assignment already and then we can move on with actually deploying IPv6.
Luckily the MS users that are moving to Linux right now are the smarter / more inquisitive members of the MS crowd. It isn't too hard for the Linux community to support and assimilate them. Lets hope there isn't a large rush of the unwashed masses to Linux. It will be like "Eternal September" all over again.
Is this the same ratio as the number of VCR's that are flashing 12:00?
Your arithmetic is up the shoot.
64 ASCII characters translates to 128 hex digits.
128 hex digits (four bits each) is 512 bits.
It is?
A hex pre-shared key (PSK) would be:
0x75aaa618b013586721413a494bd515151ae73a28aeac8d951c9d98a0b2099af6
This is a 256-bit number. Remember, each hex "digit" only represents 0-15 or 4-bits of information.
WPA2 passwords can be either 0-63 character strings which will be converted to a 64-character hex key by the software, or can be specified as a 64-character hex key directly. Since the keyspace to guess a 64-character hex key is 2^256 choices long, the attacker is going to spend a very, very long time trying to guess the password.
My recommendation has always been that people that want the ultimate security use random keys pulled from /dev/random and converted to a hexadecimal number. That key should then be input using the hex key option. While they are at it, they should also turn off WEP and WPA1, turn off TKIP and only allow WPA2 with CCMP. That will give the crackers something hard to chew on.
The best reason for them to do other OS's is that it forces them to do a better job of dividing the program into OS-dependent and OS-independent parts. The longer they wait, the harder it will be to unravel things.
I'm not about to pay some 2x 15 cents so that the phone company can shuttle one under 256 byte message to my sweetie. What we did was get a pair of Google HTC G-1 phones and we use the IM app to "text". Not only is it faster, but there is no additional cost to sending each message. The transport (at least for google-talk, which is what we use) is your basic IP, which is billed at a flat rate of ~$25/mo.
Same here. This is the point I stopped reading too. Anybody that thinks that a PC takes 89 watts per hour isn't worth listening to for technical advice. The next line just cemented it for me "If it's left on overnight for 16 hours, it consumes 1.42kW." Aaarrrrg. How did our basic science education go so wrong??? Please tell me that this guy is really a movie reviewer that is sitting in for the technical person as they take the holidays off.
Maybe they don't want the more affluent citizens (and government officials) tracked by every terrorist network capable of bribing a cell phone technician? There is no telling what capabilities the CALEA / E911 subroutines in the cell phones provide, but one thing is clear, if the positional information is available to the cell phone operators, it will be used by organised crime and terrorists looking to target specific people.
Who cares what ISP's do? If anyone cared they could run their own dns server and get all the protection they wanted. The problem is the lard-asses running the top-level domains. All but a very small handful refuse to sign the zones they are entrusted with. If you want to pass a law to light a fire under someone, that is the group of operators you need to target.
I wish the message would have said something along the lines of "The Signing Authority that signed this certificate is unknown. This means that the name associated with this certificate may not be correct. The encryption and securing of your data as it travels across the net is not compromised in any way. Feel free to use this certificate to secure your data, just don't trust the name."
I thought it would be obvious what attacks dnssec protects from -- the ones TFM is talking about -- namely cache pollution from spoofed replies.
I'm surprised that more folks here aren't running their own resolvers. It isn't that hard, especially if you don't need to act as an authoritative server for serving your own domains and just need a recursive resolver. One nice hack you can configure if you run your own resolver is dnssec - cryptographically secured dns lookup. While there aren't many dns zones that are cryptographically signed yet, there are a little over 10,000 (see http://secspider.cs.ucla.edu/ ). That is a start. Unless people start using dnssec and demanding that their websites be in secured dns zones, companies won't be bother to do the work needed to configure their dns zones with dnssec. A pdf with simple instructions for setting up dnssec can be found here. I set up my domains and resolvers this way, and it only took an afternoon to get acquainted enough with the concepts to bumble through the instructions. I've been running it for a few days now and it seems to be working just fine. http://www.isc.org/sw/bind/docs/DNSSEC_in_6_minutes.pdf