First, barring some big change on Red Hat's and Canonical's position on UEFI secure boot, I don't think you're going to see any other entity besides Microsoft be able to sign UEFI executables. The code signing in UEFI secure boot is more like Microsoft's driver signing program than Android's app signing. All code must be signed by Microsoft. The UEFI secure boot spec says that code must be signed directly by the private key corresponding to the public key in the UEFI key store. There's no mechanism to issue a firmware developer their own certificate that's rooted in a key in the key store. So, someone can't quietly sign a UEFI executable. Microsoft isn't going to be inspecting UEFI executables for malware- but they are going to make sure they know who asked for a particular executable to be signed. They want to be able to trace malware back to the author, in the event it does get written and signed.
Also, there are revocation mechanisms for signatures in UEFI secure boot (the "forbidden list"), and Microsoft's requirements state that manufacturers must implement that functionality. Otherwise this type of signing is almost pointless.
Yep, that's true. Any bootloader, including bootloaders on boot CD/DVDs, will need to be signed when UEFI secure boot is enabled. You'll probably need to disable UEFI secure boot when using old add-in cards, like discrete video cards, too. At least, I think you''ll have to if you want to be able to be able to use your monitor in the preboot environment.
That actually raises an interesting question though... If you have a motherboard with UEFI secure boot enabled by default, and you try to use an old video card that doesn't have a signed UEFI device driver, how would you even go into the BIOS settings to turn off secure boot?
If GPLv3 actually forbids a useful security mechanism, then GPLv3 is broken. Some people, like Linus Torvalds, already think it is. So, if you really aren't allowed to digitally sign GRUB due to GPLv3 (which I think is highly questionable), then the right answer is to switch bootloaders to one released under a more reasonable license. If the FOSS community found themselves in that position by not creating any GPLv2 or BSD licensed UEFI-compatible bootloaders, then its going to be up to them to get themselves out of that mess.
And, Microsoft already said their signing service would sign third-party bootloaders.
I'm really confused by Matthew Garrett's assertion that secure boot creates problems for virtualbox, OS device drivers, and other kernel modules. UEFI secure boot only applies to UEFI executables (basically UEFI device drivers and bootloaders). Only the bootloader hands off control to the OS, UEFI secure boot's job is done. It's up to the OS bootloader to decide if it wants to check a signature on the OS. And from there, its up to the OS to decide if it wants to verify signature on other kernel modules, including drivers. If the Linux folks aren't worried about malicious device drivers acting as rootkits, they don't need to verify device drivers. It's just that simple.
And maybe if Matthew and the FOSS community are that concerned about standardized key formats for UEFI they should actually join the UEFI Forum. Red Hat and Canonical have certainly been invited to the table, but they instead choose to criticize from the outside rather than be part of the solution. Microsoft has gone out of their way to try to placate the FOSS folks here, at least on x86 (I agree that the situation on ARM is a bit different). MS will sign other bootloaders, if someone will submit one, allowing Linux folks to take partial advantage of UEFI secure boot. MS is requiring user-configurable trust anchors on x86, which is exactly what Red Hat and Canonical asked for.
I really don't understand Matthew here. He got what he wanted on x86. I can understand him not being happy with the requirements for ARM systems, but he should be ecstatic with Microsoft's new draft requirements for x86 systems.
I agree servers are attractive targets. But I think the main reason they're attractive is because they have a lot of potentially high-value data on them, depending on what they are. A server, by itself, is a valuable target. Clients, and in particular clients for home users, are really just valuable en masse. Virus, worm and/or trojan-style malware makes a lot of sense for client machines, where an attacker probably isn't going to go to any great trouble to take over any particular machine- they just want a lot of machines. And once they get control of a client machine, they're not going to spend hours figuring out what data on it is valuable. Attacks on clients just tend to be a lot more automated from top to bottom.
Because servers are valuable individually, an attacker will spend more time on it. Mainly, the method of attack will be different. They'll craft their own exploit code to get in. They probably won't just add it to a botnet they control. And, I think you have to expect that any time an attacker does something "noisy" on a server, like using it to send out lots of spam, it will get detected rapidly. But, I'm sure there are situations where that happens. I sure there are lots of insecure SMTP servers out there that get hacked into each day.
Even iOS has privilege escalation vulnerabilities. The iOS security model doesn't decrease privilege escalation vulnerabilities- it just makes them more difficult to exploit, since its hard to run even low-privilege code. You can consider Charlie Miller's recent attack, as well as the old PDF buffer overflow (CVE-2010-2973), privilege escalation attacks.
What sort of crazy conspiracy theory do you have twirling around in your head that makes you think Microsoft would rather block malware by using AV software than securing the OS? What makes you think Microsoft, who has the software industry's most advanced and rigorous secure software development methodology (SDL), isn't already trying to secure the OS?
Any piece of moderately complex software is going to have vulnerabilities. But the bigger problem for Microsoft is that users need to be able to run untrusted code on their boxes. And trusted code that really isn't trustworthy (thanks, Adobe). You could point to access control mechanisms and sandboxing, but in reality every modern OS has privilege escalation vulnerabilities. You have to assume anyone that can execute code on your box, even in userspace, can take control of that box. Mac OS X and Linux have the same sorts of vulnerabilities.
They definitely would. Baked-in AV would be probably be great for most home users, but businesses would want something that they can more easily centrally manage. Microsoft has gone to great lengths to make it possible to centrally manage Windows, but certain features running on/under Windows are not always so easy to manage (I'll looking at you, Bitlocker).
As another commenter pointed out, most AV companies would stay alive on their business sales. Most probably already make the vast majority of money on business sales. There are probably a few that are heavily dependent on OEM sales, but that's going to be the exception. Those are probably also the AV distributions with malware database subscriptions that run out after 6-12 months, whereafter the user is basically just operating without protection.
Servers are generally managed by someone at least half-competent- at least compared to most users' home desktops. A Linux server isn't a particularly attractive target for malware developers. In the grand scheme of things, there aren't enough of them compared to Windows laptops/desktops, and the attack method is more difficult because you shouldn't have people running code from outside the server. Even if a server did get infected with malware, it should be detected relatively quickly. In the end, it's just not worth it.
That's not to say Linux servers aren't attractive hacking targets. They absolutely are. And they absolutely get hacked into all the time. I really don't see why Linux would fare any better than Windows at dealing with malware if it controlled 80-90% of the client market.
OK. I'm not sure what you're worried about, but you can do whatever you want to your APs. But, did you change the MAC address for the Wifi interface, or just the MAC address for the WAN interface? Most firmwares only let you change the MAC for the WAN interface.
If your WiFi router firmware lets you change your WiFi MAC address (which the DD-WRT firmware lets you do), you could change that all the time without creating any problems with your cable modem. As long as the WAN MAC stays the same you won't have any problems.
Notably, the first link says: "These calculations are performed live on the iPhone using a crowd-sourced database of Wi-Fi hotspot and cell tower data that is generated by tens of millions of iPhones sending the geo-tagged locations of nearby Wi-Fi hotspots and cell towers in an anonymous and encrypted form to Apple."
Apple's implementation is different than Google's and Skyhook's, particularly as it relates to how a phone estimates its location from the visible APs, but its still sending geotagged MAC addresses up to a mothership.
Your absolutely right that a cell phone doesn't need to use wifi to get an estimate on where it is. But, as I said before, wifi triangulation is much, much more accurate. That's not necessarily a big deal if you're just using it to assist GPS, but it might be if you're using it as an alternative to GPS (for instance, if you're using an iPod touch, or you're inside a big building and can't see GPS satellites). Apple's Q&A says the iPhone will use geotagged wifi information from their database in addition to cell tower information.
My iPod touch is not figuring out where it is based on IP address. If you turn on location services in the settings its using the geotagged wifi database. That's how its able to pinpoint your location to around 100 meters or so. There actually seems to be a bit of an inconsistency between the two Apple pages. The first one makes it sound like the iPhone has its own cache of geotagged APs, but the second one points out that the iPod Touch needs an active Internet connection to work. I've noticed that on my iPod Touch. That implies that its sending something up, and getting a response back. Maybe the iPod just passes up the MAC addresses of visible APs, and it gets back geotagged MAC addresses, and does the triangulation computations on the iPod.
I don't understand what point you're trying to make in your second paragraph. You're right that Apple devices don't auto connect without user authorization. That's true, but irrelevant. iOS devices can certainly see the MAC addresses of visible APs without connecting to them.
Oops, I forgot to finish a sentence there. I meant to say have you ever wondered why cell phones lock on to GPS signals much, much faster than GPS navigation systems that have been off for a while? It's because the cell phones get a head start by using cell tower and WiFi data and querying these location services.
Cell phones can use cell tower triangulation, but most modern cell phones will more heavily rely on wifi triangulation because its significantly more accurate. A phone only uses just cell tower triangulation if GPS and Wifi are turned off (or if there aren't enough visible wifi access points available). But even if GPS is turned on, phones will still query the database using visible cell phone towers and wifi APs because it helps them get a GPS signal lock much, much faster. Haven't you ever wondered why
You're right that for an iPod Touch to use this it needs an active Internet connection. But its doing the same thing- querying a web-based service with the MAC addresses of currently visible APs, including the ones that it isn't connected to. You just need the active internet connection because otherwise the iPod doesn't have a way to query the web-based service.
iPhones (and Android phones) are part of the information-gathering system. Assuming you have GPS on, your phone is keeping track of unsecured and secured wifi APs, along with their locations, and reporting them up to the mothership. Google also uses their Street View cars to map access points. Skyhook sort of works the same way. Some software on mobile phones use the Skyhook data source, instead of whatever the phone vendor might provide. Mapquest on Android does this. There's a Skyhook service running in the background that captures MAC address and location data, and passes it up to the Skyhook mothership.
Except that depending on your Wifi management software, some devices will see a device with the same SSID but a different MAC address as a different network, and make you manually reconnect to it.
The ironic thing about you complaining that geeks give Google too much latitude is that other companies (including Skyhook and Apple) do roughly the same thing Google does, yet Google is the main one getting heat for this. The other companies don't even have a way for people to opt out.
I didn't see that in the article at all. The ARS article explicitly said it was Wifi. Besides 2.4 and 5Ghz, where else is there enough contiguous unlicensed spectrum for anything like this to plausibly work?
That's only true for using a quantum computer to break symmetric crypto. Asymmetric crypto algorithms that rely on the difficulty of factoring or computing discrete logs are hit much harder.
I highly doubt AES-128 will be crackable in 20 years. You're not going to be able to brute force a 128 bit key in 20 years, so you'd need to hope that someone discovers a weakness in AES. Keep in mind that no one ever found a serious weakness in DES- it was only cracked because a 56-bit key size is way too small. A 128 bit key is 2^72 harder to brute force than a 56-bit key.
But, quantum computers can crack AES-128 in 2^64 work, so maybe its vulnerable. But, I think you'd be hard-pressed to find a cryptographer that thinks AES-256 is going to be broken in 20 years.
You corrected yourself, but I want to stress that asymmetric algorithms relying on the hardness of factoring and discrete logs both fall to quantum computers. That means DH, ElGamal, and DSA all fall. Some other crypto algorithms fall too, like identity-based encryption algorithms that rely on difficulty of the bilinear Diffie-Hellman problem.
There are alternatives, though. Probably the closest thing to a drop-in replacement for RSA for key establishment is NTRUEncrypt. But, NTRU isn't necessarily a good replacement for ECC (or even RSA), because it has larger key sizes. That may or may not be a problem, depending on the protocol. SSH and TLS should be fine. DNSSEC is more of a problem, since there's only so much space available in the packet format.
It is a real concern though. Quantum computers are by no means around the corner, but we're in serious trouble if someone manages to build a working quantum computer. So many of our important crypto protocols rely on RSA, DH, ECC-DH, etc. There actually are some pretty decent alternatives to the current used set of asymmetric algorithms, but getting those algorithms into standards (e.g., getting Ntru into the TLS cipher suite) is going to take time, and getting those updated standards implemented and deployed will take even longer.
In some cases, protocols will have to change because of the new asymmetric algorithms. Some protocols really need to have small public keys, because their packet formats are only so big. ECC is great for that. But, the asymmetric algorithms all have larger public keys than ECC to achieve a comparable level of security.
This is a real problem that people need to start thinking about. Of course, its not the slashdot crowd that is going to solve this problem.
Security level usually refers to the number of bits of security in a given algorithm as a given key size. It's easiest to explain it using an example of a secure symmetric encryption algorithm, like AES. Brute force attacks on AES are still the best attack, enough though the biclique attack has lower computational complexity on paper. A brute force attack on AES with a 128-bit key takes about 2^128 work. So, you would say is has a 128-bit security strength.
Having a security strength means going from 128-bits to 64-bits. So, having the security strength doesn't mean you've made something twice as fast to attack. In that example it means you've made it 2^64 times faster.
In the case of asymmetric algorithms you have to look at the computational complexity of the best known attacks. So, for something like RSA, that means the best known factoring algorithms. Looking at the computational complexity of the number field sieve, you come to the conclusion that a 2048-bit RSA key takes about 2^112 work, so it has a security strength of 112-bits.
Slashdot Mirror
First, barring some big change on Red Hat's and Canonical's position on UEFI secure boot, I don't think you're going to see any other entity besides Microsoft be able to sign UEFI executables. The code signing in UEFI secure boot is more like Microsoft's driver signing program than Android's app signing. All code must be signed by Microsoft. The UEFI secure boot spec says that code must be signed directly by the private key corresponding to the public key in the UEFI key store. There's no mechanism to issue a firmware developer their own certificate that's rooted in a key in the key store. So, someone can't quietly sign a UEFI executable. Microsoft isn't going to be inspecting UEFI executables for malware- but they are going to make sure they know who asked for a particular executable to be signed. They want to be able to trace malware back to the author, in the event it does get written and signed.
Also, there are revocation mechanisms for signatures in UEFI secure boot (the "forbidden list"), and Microsoft's requirements state that manufacturers must implement that functionality. Otherwise this type of signing is almost pointless.
Yes, what you just described is the bootloader.
Yep, that's true. Any bootloader, including bootloaders on boot CD/DVDs, will need to be signed when UEFI secure boot is enabled. You'll probably need to disable UEFI secure boot when using old add-in cards, like discrete video cards, too. At least, I think you''ll have to if you want to be able to be able to use your monitor in the preboot environment.
That actually raises an interesting question though... If you have a motherboard with UEFI secure boot enabled by default, and you try to use an old video card that doesn't have a signed UEFI device driver, how would you even go into the BIOS settings to turn off secure boot?
If GPLv3 actually forbids a useful security mechanism, then GPLv3 is broken. Some people, like Linus Torvalds, already think it is. So, if you really aren't allowed to digitally sign GRUB due to GPLv3 (which I think is highly questionable), then the right answer is to switch bootloaders to one released under a more reasonable license. If the FOSS community found themselves in that position by not creating any GPLv2 or BSD licensed UEFI-compatible bootloaders, then its going to be up to them to get themselves out of that mess.
And, Microsoft already said their signing service would sign third-party bootloaders.
I'm really confused by Matthew Garrett's assertion that secure boot creates problems for virtualbox, OS device drivers, and other kernel modules. UEFI secure boot only applies to UEFI executables (basically UEFI device drivers and bootloaders). Only the bootloader hands off control to the OS, UEFI secure boot's job is done. It's up to the OS bootloader to decide if it wants to check a signature on the OS. And from there, its up to the OS to decide if it wants to verify signature on other kernel modules, including drivers. If the Linux folks aren't worried about malicious device drivers acting as rootkits, they don't need to verify device drivers. It's just that simple.
And maybe if Matthew and the FOSS community are that concerned about standardized key formats for UEFI they should actually join the UEFI Forum. Red Hat and Canonical have certainly been invited to the table, but they instead choose to criticize from the outside rather than be part of the solution. Microsoft has gone out of their way to try to placate the FOSS folks here, at least on x86 (I agree that the situation on ARM is a bit different). MS will sign other bootloaders, if someone will submit one, allowing Linux folks to take partial advantage of UEFI secure boot. MS is requiring user-configurable trust anchors on x86, which is exactly what Red Hat and Canonical asked for.
I really don't understand Matthew here. He got what he wanted on x86. I can understand him not being happy with the requirements for ARM systems, but he should be ecstatic with Microsoft's new draft requirements for x86 systems.
I agree servers are attractive targets. But I think the main reason they're attractive is because they have a lot of potentially high-value data on them, depending on what they are. A server, by itself, is a valuable target. Clients, and in particular clients for home users, are really just valuable en masse. Virus, worm and/or trojan-style malware makes a lot of sense for client machines, where an attacker probably isn't going to go to any great trouble to take over any particular machine- they just want a lot of machines. And once they get control of a client machine, they're not going to spend hours figuring out what data on it is valuable. Attacks on clients just tend to be a lot more automated from top to bottom.
Because servers are valuable individually, an attacker will spend more time on it. Mainly, the method of attack will be different. They'll craft their own exploit code to get in. They probably won't just add it to a botnet they control. And, I think you have to expect that any time an attacker does something "noisy" on a server, like using it to send out lots of spam, it will get detected rapidly. But, I'm sure there are situations where that happens. I sure there are lots of insecure SMTP servers out there that get hacked into each day.
Even iOS has privilege escalation vulnerabilities. The iOS security model doesn't decrease privilege escalation vulnerabilities- it just makes them more difficult to exploit, since its hard to run even low-privilege code. You can consider Charlie Miller's recent attack, as well as the old PDF buffer overflow (CVE-2010-2973), privilege escalation attacks.
What sort of crazy conspiracy theory do you have twirling around in your head that makes you think Microsoft would rather block malware by using AV software than securing the OS? What makes you think Microsoft, who has the software industry's most advanced and rigorous secure software development methodology (SDL), isn't already trying to secure the OS?
Any piece of moderately complex software is going to have vulnerabilities. But the bigger problem for Microsoft is that users need to be able to run untrusted code on their boxes. And trusted code that really isn't trustworthy (thanks, Adobe). You could point to access control mechanisms and sandboxing, but in reality every modern OS has privilege escalation vulnerabilities. You have to assume anyone that can execute code on your box, even in userspace, can take control of that box. Mac OS X and Linux have the same sorts of vulnerabilities.
They definitely would. Baked-in AV would be probably be great for most home users, but businesses would want something that they can more easily centrally manage. Microsoft has gone to great lengths to make it possible to centrally manage Windows, but certain features running on/under Windows are not always so easy to manage (I'll looking at you, Bitlocker).
As another commenter pointed out, most AV companies would stay alive on their business sales. Most probably already make the vast majority of money on business sales. There are probably a few that are heavily dependent on OEM sales, but that's going to be the exception. Those are probably also the AV distributions with malware database subscriptions that run out after 6-12 months, whereafter the user is basically just operating without protection.
Servers are generally managed by someone at least half-competent- at least compared to most users' home desktops. A Linux server isn't a particularly attractive target for malware developers. In the grand scheme of things, there aren't enough of them compared to Windows laptops/desktops, and the attack method is more difficult because you shouldn't have people running code from outside the server. Even if a server did get infected with malware, it should be detected relatively quickly. In the end, it's just not worth it.
That's not to say Linux servers aren't attractive hacking targets. They absolutely are. And they absolutely get hacked into all the time. I really don't see why Linux would fare any better than Windows at dealing with malware if it controlled 80-90% of the client market.
OK. I'm not sure what you're worried about, but you can do whatever you want to your APs. But, did you change the MAC address for the Wifi interface, or just the MAC address for the WAN interface? Most firmwares only let you change the MAC for the WAN interface.
If your WiFi router firmware lets you change your WiFi MAC address (which the DD-WRT firmware lets you do), you could change that all the time without creating any problems with your cable modem. As long as the WAN MAC stays the same you won't have any problems.
Look at Apple's Q&A on this topic:
http://www.apple.com/pr/library/2011/04/27Apple-Q-A-on-Location-Data.html
You can also look at their support page on location services:
http://support.apple.com/kb/ht1975
Notably, the first link says: "These calculations are performed live on the iPhone using a crowd-sourced database of Wi-Fi hotspot and cell tower data that is generated by tens of millions of iPhones sending the geo-tagged locations of nearby Wi-Fi hotspots and cell towers in an anonymous and encrypted form to Apple."
Apple's implementation is different than Google's and Skyhook's, particularly as it relates to how a phone estimates its location from the visible APs, but its still sending geotagged MAC addresses up to a mothership.
Your absolutely right that a cell phone doesn't need to use wifi to get an estimate on where it is. But, as I said before, wifi triangulation is much, much more accurate. That's not necessarily a big deal if you're just using it to assist GPS, but it might be if you're using it as an alternative to GPS (for instance, if you're using an iPod touch, or you're inside a big building and can't see GPS satellites). Apple's Q&A says the iPhone will use geotagged wifi information from their database in addition to cell tower information.
My iPod touch is not figuring out where it is based on IP address. If you turn on location services in the settings its using the geotagged wifi database. That's how its able to pinpoint your location to around 100 meters or so. There actually seems to be a bit of an inconsistency between the two Apple pages. The first one makes it sound like the iPhone has its own cache of geotagged APs, but the second one points out that the iPod Touch needs an active Internet connection to work. I've noticed that on my iPod Touch. That implies that its sending something up, and getting a response back. Maybe the iPod just passes up the MAC addresses of visible APs, and it gets back geotagged MAC addresses, and does the triangulation computations on the iPod.
I don't understand what point you're trying to make in your second paragraph. You're right that Apple devices don't auto connect without user authorization. That's true, but irrelevant. iOS devices can certainly see the MAC addresses of visible APs without connecting to them.
Oops, I forgot to finish a sentence there. I meant to say have you ever wondered why cell phones lock on to GPS signals much, much faster than GPS navigation systems that have been off for a while? It's because the cell phones get a head start by using cell tower and WiFi data and querying these location services.
Cell phones can use cell tower triangulation, but most modern cell phones will more heavily rely on wifi triangulation because its significantly more accurate. A phone only uses just cell tower triangulation if GPS and Wifi are turned off (or if there aren't enough visible wifi access points available). But even if GPS is turned on, phones will still query the database using visible cell phone towers and wifi APs because it helps them get a GPS signal lock much, much faster. Haven't you ever wondered why
You're right that for an iPod Touch to use this it needs an active Internet connection. But its doing the same thing- querying a web-based service with the MAC addresses of currently visible APs, including the ones that it isn't connected to. You just need the active internet connection because otherwise the iPod doesn't have a way to query the web-based service.
iPhones (and Android phones) are part of the information-gathering system. Assuming you have GPS on, your phone is keeping track of unsecured and secured wifi APs, along with their locations, and reporting them up to the mothership. Google also uses their Street View cars to map access points. Skyhook sort of works the same way. Some software on mobile phones use the Skyhook data source, instead of whatever the phone vendor might provide. Mapquest on Android does this. There's a Skyhook service running in the background that captures MAC address and location data, and passes it up to the Skyhook mothership.
What would stop Skyhook and/or Apple from sabotaging Google's database using their own lists of MAC addresses and SSIDs?
Except that depending on your Wifi management software, some devices will see a device with the same SSID but a different MAC address as a different network, and make you manually reconnect to it.
The ironic thing about you complaining that geeks give Google too much latitude is that other companies (including Skyhook and Apple) do roughly the same thing Google does, yet Google is the main one getting heat for this. The other companies don't even have a way for people to opt out.
I didn't see that in the article at all. The ARS article explicitly said it was Wifi. Besides 2.4 and 5Ghz, where else is there enough contiguous unlicensed spectrum for anything like this to plausibly work?
That's only true for using a quantum computer to break symmetric crypto. Asymmetric crypto algorithms that rely on the difficulty of factoring or computing discrete logs are hit much harder.
NSA itself uses what the rest of us use. AES-256 is cleared for top secret data
Believe it or not, but NSA wants to see strong crypto available in commercial products, because they use a lot of commercial products.
I highly doubt AES-128 will be crackable in 20 years. You're not going to be able to brute force a 128 bit key in 20 years, so you'd need to hope that someone discovers a weakness in AES. Keep in mind that no one ever found a serious weakness in DES- it was only cracked because a 56-bit key size is way too small. A 128 bit key is 2^72 harder to brute force than a 56-bit key.
But, quantum computers can crack AES-128 in 2^64 work, so maybe its vulnerable. But, I think you'd be hard-pressed to find a cryptographer that thinks AES-256 is going to be broken in 20 years.
You corrected yourself, but I want to stress that asymmetric algorithms relying on the hardness of factoring and discrete logs both fall to quantum computers. That means DH, ElGamal, and DSA all fall. Some other crypto algorithms fall too, like identity-based encryption algorithms that rely on difficulty of the bilinear Diffie-Hellman problem.
There are alternatives, though. Probably the closest thing to a drop-in replacement for RSA for key establishment is NTRUEncrypt. But, NTRU isn't necessarily a good replacement for ECC (or even RSA), because it has larger key sizes. That may or may not be a problem, depending on the protocol. SSH and TLS should be fine. DNSSEC is more of a problem, since there's only so much space available in the packet format.
It is a real concern though. Quantum computers are by no means around the corner, but we're in serious trouble if someone manages to build a working quantum computer. So many of our important crypto protocols rely on RSA, DH, ECC-DH, etc. There actually are some pretty decent alternatives to the current used set of asymmetric algorithms, but getting those algorithms into standards (e.g., getting Ntru into the TLS cipher suite) is going to take time, and getting those updated standards implemented and deployed will take even longer.
In some cases, protocols will have to change because of the new asymmetric algorithms. Some protocols really need to have small public keys, because their packet formats are only so big. ECC is great for that. But, the asymmetric algorithms all have larger public keys than ECC to achieve a comparable level of security.
This is a real problem that people need to start thinking about. Of course, its not the slashdot crowd that is going to solve this problem.
Security level usually refers to the number of bits of security in a given algorithm as a given key size. It's easiest to explain it using an example of a secure symmetric encryption algorithm, like AES. Brute force attacks on AES are still the best attack, enough though the biclique attack has lower computational complexity on paper. A brute force attack on AES with a 128-bit key takes about 2^128 work. So, you would say is has a 128-bit security strength.
Having a security strength means going from 128-bits to 64-bits. So, having the security strength doesn't mean you've made something twice as fast to attack. In that example it means you've made it 2^64 times faster.
In the case of asymmetric algorithms you have to look at the computational complexity of the best known attacks. So, for something like RSA, that means the best known factoring algorithms. Looking at the computational complexity of the number field sieve, you come to the conclusion that a 2048-bit RSA key takes about 2^112 work, so it has a security strength of 112-bits.