Of course this is about power shifting towards governments in general. This is to be expected - after all, we can't just have random people running the internet and governments happen to be the very things that represent their countries internationally
(Emphasis mine.)
Why not? That's basically what Jon Postel did: he basically singlehandedly administered the DNS root and was IANA.
Sure, things are different now, but we certainly have had random people running the internet. It worked then, why not now?
If VeriSign gets caught issuing bogus certs for the government, browser vendors will revoke their roots. That's basically a death sentence to companies like VeriSign (rather, their cert-issuing division).
I wouldn't be too sure of that.
Of all the companies that have aided the NSA, how many are out of business or even really hurting?
Companies like what? The ones making network-tapping hardware and whatnot cater toward a limited market, not the general public. Certificate authorities directly transact with server administrators, but their primary audience are end-users and they have wide public exposure. If a CA was found to be doing shady things, browsers would remove their roots. That'd basically kill off the offending CA.
>If VeriSign gets caught issuing bogus certs for the government, browser vendors will revoke their roots.
HAHAHAHAno. Thanks to the demon that is backwards compatibility browser vendors have implicitly or explicitly confirmed that they cannot actually revoke root certs. Or, more specifically, that many websites rely on that particular root to verify their identity and would break horribly if a root cert got revoked. i.e. revoking a misbehaving root will break the web.
Why not? There have been roots that have been revoked due to being compromised and which have issued bogus certs (e.g. DigiNotar). That's caused some chaos, but people adapted.
Sure, VeriSign is large and commands (either directly or through its subsidiaries) a substantial fraction of the CA market. Nuking it would be a Very Big Deal that browsers wouldn't take lightly, but I have no doubt that if it were shown that VeriSign (or Comodo, or other CAs) were found to be issuing bogus certs for the government to compromise people, they'd get their roots pulled by browsers. That's a death sentence for a CA, hence my skepticism in response to the proposal that they're actively assisting governments.
A better solution would be the ability to provide multiple root certs, which is not technically feasible today, and won't be for a while - even things like SSL vhosts are considered unreliable due to the prevalence of legacy browsers that don't know how to use the proper TLS extensions for hostname identification. So maybe in 10 years we can start telling site operators that they can turn on multiple certs, and 10 years after that browser vendors will have enough data to determine if it's safe to actually revoke a root cert or not. In the meantime you will have to convince HTTPS services that it's worth paying n times as much in certification costs to avoid a hypothetical root revocation.
What good is https going to be against the state? You think they can not coerce Verisign et al to hand over a copy of the root keys?
Sure, they could, but I doubt they are.
If VeriSign gets caught issuing bogus certs for the government, browser vendors will revoke their roots. That's basically a death sentence to companies like VeriSign (rather, their cert-issuing division).
While typical users won't notice, there's still plenty of risk to getting caught, particularly when targeting anyone using major web properties: Chrome, for example, has a bunch of high-profile sites "pinned" and will report back to Google if bogus certs are being used (they identified a bunch of MITMing with compromised certs in Iran in this way). Other add-ons like Perspectives make it easier to detect if unexpected certs are showing up.
Could they get away with issuing infrequently-used certs for highly-targeted, one-off uses? Possibly, but each time they do the risk to their entire business increases.
I suspect the government would much prefer to do things sneakily in the shadows, rather than involving major CAs in such a risky role.
Compared to what you can get in Europe or Asia, those "decent prices" are in fact insanely expensive.
Perhaps. Depends on the location and provider. Here in Bern, Switzerland, the cable company offers 250/15 internet for CHF 89/month ($98 USD). That's only $10 more than the 200/200 for $89.95 offering. Not unreasonable. For CHF 105/month they package a bunch of cable TV channels (including European and American sports) and 250/15 internet.
Swisscom, the incumbent phone company, has fiber-to-the-home. 300/60 internet with even more TV channels costs CHF 154/month. They offer up to 1000/100 connection if you're willing to pay and extra CHF 80/month above the CHF 154 rate. That's USD $258, only $8 more than the 1000/1000 plan offered in Clarksville (though the Swisscom offering does include TV. Phone is an extra CHF 15).
Then again, Switzerland does tend to be expensive. You may get cheaper service in other countries, but it is quite comparable in terms of cost here.
While I wish they allowed free reissuance of certs at any time, I don't really see why requiring revocation is a showstopper.
It's not a showstopper, per se, but they do charge a revocation fee ($25, I think?), so that makes it decidedly less than free.
True, but how often does one need to revoke a certificate? Other than Heartbleed, I think I've only revoked one certificate in the last 10 years or so. Amortized over that timeframe, the costs are negligible. That said, I would like it if StartSSL would offer free revocations in the case of something like Heartbleed, where certs are compromised through no fault of the customer, but I understand the business reasons for not doing so (CRL/OCSP isn't free).
Of course, I've abandoned several certs where I deleted a VM hosting a site I no longer needed, but since the cert was not compromised and the private key was deleted, I just let the expiration timer run out. No big deal.
To clarify I fully understand why startSSL do this, they are a buisness and they need to make money and they are certainly the best value widely recognised CA I have found.
I just don't think using startSSLs limited free certs as a rebuttal to claims that SSL increases costs for website operators is reasonable. Either you pay to get the wildcard certs or you pay to get extra IPv4 addresses or some combination of the two.
Why not just use SNI? I have multiple SSL-enabled virtualhosts running on a single server, and other than Internet Explorer on Windows XP and Android 2.x (neither of which I care about, as the former is EOL while the latter is effectively EOL) every browser on desktop and mobile devices works properly. I spend more money every two weeks on caffeinated beverages than my entire annual budget for SSL certs, and I have more than most. My cert budget is dwarfed by hosting costs (which I pay regardless of SSL support or not).
If you don't care about those systems (and I don't), SNI is perfectly satisfactory. If you need to support those old systems for some reason, you're probably a commercial enterprise who can afford IP-based SSL or wildcard certs. For typical individuals or small/medium-sized organizations using SNI, adding SSL support to your sites will essentially be a non-issue in terms of cost.
If anything, Google adding a small boost to SSL-enabled sites should encourage and improve support for SNI and hopefully sweep away the few older browsers that don't support it. I'm all for it.
Gotta agree. My RT-N66U(Shibby 121) is running a crap load of stuff with zero downtime. VLAN, IPTV, VoIP, OpenVPN server and client, Print server, etc etc etc.
I've got an RT-AC68U as my access point. Not as mature firmware wise, and hard to test to it's full potential, but rock solid none the less.
ASUS can shut up and take my money.
Seconded in regards to the N66U. It's a fantastic router. I've been running Tomato Shibby for years (most recently v121) and it's been rock-solid, reliable, and stable.
There's only one downside: Tomato doesn't include the necessary kernel module for hardware accelerated WAN-to-LAN NAT/routing. This only matters if your downstream WAN bandwidth is greater than ~120Mbps. If your downstream bandwidth is less, the software routing can keep up and you'll run at full speed. If your downstream bandwidth is greater, you will be limited to ~120-130Mbps, as that's as fast as the N66U can route in software. LAN-to-LAN bandwidth will run entirely in hardware regardless of what firmware you have.
My ISP just upgraded me to a 250Mbps downstream link, so I reluctantly went back to the factory firmware to take advantage of the hardware acceleration. It's clunky and annoying compared to the elegance of the Tomato web interface, but it works. The Merlin firmware maintains the look-and-feel of the factory firmware, includes support for hardware acceleration, fixes a few bug and adds a few features (but not as many as Tomato) that makes it suck less.
2: they make the expiry artifically short (the CA industry as a whole does this but startSSLs free certs are epecially bad),
A validity time of one year is pretty standard for SSL certs (paid certs often charge per year). Could they issue them for 20 years? Sure, but a one year validity is not unusual. Class 2 certs are good for two years.
3: they refuse to renew certs until just before they expire and refuse to reissue certs without revoking the old one.
I get renewal notices two weeks prior to expiration. That's pretty reasonable. If I recall correctly, I can generate a new cert for my site any time in that two-week period, so I don't need to wait for the cert to expire before replacing it.
While I wish they allowed free reissuance of certs at any time, I don't really see why requiring revocation is a showstopper.
4: each free cert only covers a domain and one hostname under that domain (e.g. bar.com and foo.bar.com). This effectively means you end up needing one IP per hostname you want SSL on (until IE on XP becomes insignificant anyway).
That's also the case for pretty much any of the inexpensive paid certs too. You can always get a wildcard cert but most CAs charge at least $100/year for a single wildcard cert. StartSSL charges $60 for Class 2 validation, and you can issue unlimited certs (wildcard or not). Organizations can get Class 2 certified for $120 ($60 for identity verification, $60 for organization verification) and can issue unlimited certs. For a company needing more than one cert, StartSSL is still cheaper.
It's nice that there is a free (as in beer) option for some people but it's also clearly got a number of artificial restrictions on it to push people towards their paid options.
Considering their paid certs are often cheaper than comparable offerings from other CAs, it doesn't really seem unreasonable to me. Doubly so because they're run by competent people who respond promptly to inquiries, even from free users. I've been a StartSSL customer for years (and also used other CAs like GoDaddy, Comodo, Thawte, etc.) and the customer service from StartSSL has always been excellent.
If you don't want to get a StartSSL cert or they don't meet your needs, that's fine. NameCheap and others sell single-domain Comodo certs for $9/year. RapidSSL certs are a buck or two more per year. That costs less than a single beer at the local bar. Hardly a massive expense.
Quite the contrary: StartSSL is accepted by every major browser and SSL/TLS library, and has been for years.
Well-known sites, like EFF.org, LibreOffice, and others use StartSSL-issued certs and don't have any issues. Sure, they're not Google-sized sites, but they're fairly major.
That doesn't jive with my results though. At work, if I'm in the building in the center all day without appreciable service my phone doesn't last the day. If I'm at an outside wall, my phone barely makes it through the day without any significant usage, barely getting one bar. If I'm out and about I've had service work on standby for couple of days when I've forgotten to charge it overnight.
That seems to match with what I'm saying: when the phone is constantly searching for signals it has the receiver enabled all the time and the gain turned up to maximum, using more power. When it is in an area of low-but-there signal, the receiver isn't powered up as often, but the gain is still high, so it uses a medium amount of power. When you're out in the open and there's lots of signal, the receiver isn't powered up as often and the gain is low, so it uses the least amount of power.
Usually, a terrestrial phone doesn't need to do anything much to "look" for a tower, besides keeping its receiver turned on. Towers emit beacons, and if you don't hear the beacon, there's no point in you sending anything - you won't receive a reply because you don't even hear the tower's beacon.
Indeed, many (most? all?) phones won't transmit at all unless they hear the tower's beacon, since it's possible they could have been moved to a jurisdiction where it is not allowed for them to transmit on certain frequencies they would otherwise use.
Of course, keeping the receiver powered to listen for the beacon does use a not-inconsiderable amount of power, so searching for signal will use more power than a phone that is connected to the network and idle.
If the keys are stored on the box in any way then they are compromised because the box is. The synology box is rooted, any information stored on that box is compromised. If for example your root key for S3 is backed up on the NAS then it's compromised.
Agreed. That's why you shouldn't use the root S3 access key for anything (in fact, don't generate one at all). Use service-limited, least-access keys for AWS accounts: there's no reason a NAS should have an access key capable of creating EC2 instances. It should have list+write access only to S3 (and/or Glacier). If users want to delete files from S3, they should have to log in with a different user (perhaps to the AWS console) and specifically do that.
Amazon provides good options in this regard, and it's too bad if users aren't taking advantage of them.
People are glossing over this, if the box is rooted everything it knows and stores is compromised, that's how people need to be analyzing this instead of blowing it off as no big deal.
In this specific case, the malware does not seem to want to steal user data, only to encrypt it and ransom it back to users. Sure, it could steal data, but it doesn't seem to do so. It's a big deal to those who are unprepared and don't have proper backups, but it could definitely be worse.
You do realize that for the S3 backup to work Synology or the NAS (and the NAS has you Synology login info) has your login information for S3, and that if this thing is owning the NAS there is a pretty damn good chance the malware has owned your S3 instance as well right? The only way it wouldn't is if the S3 backup is totally manual.
Amazon has a very extensive authentication system -- you can easily configure the Synology with an S3 access key that only has "List Files" and "Upload Files" permissions, but not "Delete Files" or "Overwrite Files". This way, even if the Synology box gets owned or a user fat-fingers something, the files on S3 aren't at risk. You don't (and shouldn't) need to use your AWS root access keys for S3.
I have a similar setup with Amazon's Glacier: my standard access key has only list, upload, and retrieve permissions. A separate access key is required to delete files (I've configured my Glacier client, FastGlacier, to prompt me for a password when I switch to the "delete" key) so that I don't accidentally end up deleting important backups.
I'd like something like this for a mixed Windows/Mac/Linux network but the costs are just prohibitive.
Yubikeys are $25 each for the hardware, and $45 PER USER. That's just ridiculous when you scale up, and there's an awful lot of manually faffing about to get to the point that it works.
Wait, what? Where do you get the $45 per user cost? I don't see that anywhere on their website.
The "YubiCloud" (where Yubico hosts the authenticator servers) has two modes: free and premium. The free service is open to everyone, even commercial users. The premium service offers an SLA and monthly usage statistics, and costs $3/YubiKey/year (1000-unit minimum).
You can also host your own local YubiKey authentication servers and keep things entirely in-house. Yubico has reference implementations for free on their site.
For software tokens, Google Authenticator has apps for Android, iOS, and BlackBerry. They implement the TOTP standard, so any compatible code-generating software (such as the J2ME app I have on my non-smartphone) will work with it.
They also have a PAM module that works with SSH (or anything else that uses PAM). I've used it before, and it works great.
For reference, neither the apps nor the PAM module depend in any way on Google services, they don't send any data to Google, and will work perfectly happily in a totally offline environment (assuming all the servers and client apps have synchronized clocks).
I don't know about gigabit, but Steam has no problems maxing out my 150Mbps downstream link when I'm downloading games from a nearby server here in Switzerland.
The NRA has its deep pockets and resultant clout not (necessarily) from numerous individual private members but from effectively being an arms industry trade group, the USCoC of arms manufacturers and dealers.
The NSSF is the arms industry trade group. The private arms industry in the US is relatively small compared to, say, the oil, tobacco, alcohol, etc. industry and doesn't have anywhere near the same political clout as those industries. The largest source of income for the NRA is membership dues, and it's from their 5+ million members that they derive their political clout.
Nothing unfortunate about it. That only affects the rich and powerful who for all purpose defraud american taxpayers and then shift the money offshore.
Why should any american have to suffer increased deficits and taxes so a tiny elite of wealthy parasites can continue to leach american money offshore
It also affects ordinary, non-rich-and-powerful people like myself: I'm an American PhD student in Switzerland and dealing with all the tax laws purportedly targeted at shady rich people (but which overwhelmingly affect ordinary people) is a massive pain and costs my wife and I several hundred dollars per year for a tax accountant to do our reasonably straightforward (i.e. we have some US investments, retirement accounts, etc. but earn all of our income in Switzerland) taxes.
Honestly, the whole thing can be resolved by making US tax law similar to that elsewhere in the world: pretty much all the other countries tax people based on their residency, not citizenship. That is, a Canadian living in Canada will pay Canadian taxes, but a Canadian living in Switzerland only pays Swiss taxes and owes the Canadian government nothing. Americans get taxed on their global income even if they don't live in the US (though there is a certain amount below which they're not double-taxed).
It's not a super advanced scope, and doesn't compare to standalone scopes like the Rigol DS1052E, but for someone on a budget who has fairly basic needs, it's worth a shot. It was developed by a guy who was annoyed at the drawbacks of other PC-based oscilloscopes and their software.
I use mine for testing homebuilt electronics, and it does well for that. I wouldn't use it for anything significantly more than that sort of stuff, though.
Think a nightclub with laser advertising, plane flies overhead, or helicopter.
Can they be punished?
Major astronomical telescopes often use lasers for their adaptive optics systems. They coordinate with relevant authorities to insure they don't zap sensitive optics on satellites and post "plane spotters" outside so they can shut down the laser if a plane comes too close to the beam.
Of course, those lasers tend to be considerably more powerful (>5W) than handheld laser pointers (~5mW), so it might not be directly comparable, but I'd hope that any organization that is shooting lasers into the sky would have someone keeping an eye out for aircraft.
To have guns insured just like cars are, so that gun owners will always have enough funds to cover any damages that may ensue from mishandling the weapon.
If gun insurance coverage was mandatory then there'd be the right framework for a proper marketplace dynamics.
That's called "liability insurance" and is already included in typical homeowners and renters insurance policies -- the liability policy applies to incidents both on and off one's property. Pretty much everyone already has this (or should have it). It's quite inexpensive, and is typically less than $200/year for renters, so it seems that insurance companies have very little worries about gun owners.
That said, your analogy to car insurance doesn't make sense: the vast majority of car-related injuries and death are due to unintentional acts (i.e., accidents), which insurance will cover. The majority of gun-related injuries and deaths are due to intentional criminal acts, which insurance definitely will not cover. Those likely to go about committing criminal acts with their firearms are unlikely to have "gun insurance" anyway, regardless of if it's legally mandated or not. Your typical gun owner already has liability insurance through their homeowners or renters insurance.
Slashdot Mirror
Of course this is about power shifting towards governments in general. This is to be expected - after all, we can't just have random people running the internet and governments happen to be the very things that represent their countries internationally
(Emphasis mine.)
Why not? That's basically what Jon Postel did: he basically singlehandedly administered the DNS root and was IANA.
Sure, things are different now, but we certainly have had random people running the internet. It worked then, why not now?
If VeriSign gets caught issuing bogus certs for the government, browser vendors will revoke their roots. That's basically a death sentence to companies like VeriSign (rather, their cert-issuing division).
I wouldn't be too sure of that.
Of all the companies that have aided the NSA, how many are out of business or even really hurting?
Companies like what? The ones making network-tapping hardware and whatnot cater toward a limited market, not the general public. Certificate authorities directly transact with server administrators, but their primary audience are end-users and they have wide public exposure. If a CA was found to be doing shady things, browsers would remove their roots. That'd basically kill off the offending CA.
>If VeriSign gets caught issuing bogus certs for the government, browser vendors will revoke their roots.
HAHAHAHAno. Thanks to the demon that is backwards compatibility browser vendors have implicitly or explicitly confirmed that they cannot actually revoke root certs. Or, more specifically, that many websites rely on that particular root to verify their identity and would break horribly if a root cert got revoked. i.e. revoking a misbehaving root will break the web.
Why not? There have been roots that have been revoked due to being compromised and which have issued bogus certs (e.g. DigiNotar). That's caused some chaos, but people adapted.
Sure, VeriSign is large and commands (either directly or through its subsidiaries) a substantial fraction of the CA market. Nuking it would be a Very Big Deal that browsers wouldn't take lightly, but I have no doubt that if it were shown that VeriSign (or Comodo, or other CAs) were found to be issuing bogus certs for the government to compromise people, they'd get their roots pulled by browsers. That's a death sentence for a CA, hence my skepticism in response to the proposal that they're actively assisting governments.
A better solution would be the ability to provide multiple root certs, which is not technically feasible today, and won't be for a while - even things like SSL vhosts are considered unreliable due to the prevalence of legacy browsers that don't know how to use the proper TLS extensions for hostname identification. So maybe in 10 years we can start telling site operators that they can turn on multiple certs, and 10 years after that browser vendors will have enough data to determine if it's safe to actually revoke a root cert or not. In the meantime you will have to convince HTTPS services that it's worth paying n times as much in certification costs to avoid a hypothetical root revocation.
Agreed. That would be nice.
What good is https going to be against the state? You think they can not coerce Verisign et al to hand over a copy of the root keys?
Sure, they could, but I doubt they are.
If VeriSign gets caught issuing bogus certs for the government, browser vendors will revoke their roots. That's basically a death sentence to companies like VeriSign (rather, their cert-issuing division).
While typical users won't notice, there's still plenty of risk to getting caught, particularly when targeting anyone using major web properties: Chrome, for example, has a bunch of high-profile sites "pinned" and will report back to Google if bogus certs are being used (they identified a bunch of MITMing with compromised certs in Iran in this way). Other add-ons like Perspectives make it easier to detect if unexpected certs are showing up.
Could they get away with issuing infrequently-used certs for highly-targeted, one-off uses? Possibly, but each time they do the risk to their entire business increases.
I suspect the government would much prefer to do things sneakily in the shadows, rather than involving major CAs in such a risky role.
Compared to what you can get in Europe or Asia, those "decent prices" are in fact insanely expensive.
Perhaps. Depends on the location and provider. Here in Bern, Switzerland, the cable company offers 250/15 internet for CHF 89/month ($98 USD). That's only $10 more than the 200/200 for $89.95 offering. Not unreasonable. For CHF 105/month they package a bunch of cable TV channels (including European and American sports) and 250/15 internet.
Swisscom, the incumbent phone company, has fiber-to-the-home. 300/60 internet with even more TV channels costs CHF 154/month. They offer up to 1000/100 connection if you're willing to pay and extra CHF 80/month above the CHF 154 rate. That's USD $258, only $8 more than the 1000/1000 plan offered in Clarksville (though the Swisscom offering does include TV. Phone is an extra CHF 15).
Then again, Switzerland does tend to be expensive. You may get cheaper service in other countries, but it is quite comparable in terms of cost here.
While I wish they allowed free reissuance of certs at any time, I don't really see why requiring revocation is a showstopper.
It's not a showstopper, per se, but they do charge a revocation fee ($25, I think?), so that makes it decidedly less than free.
True, but how often does one need to revoke a certificate? Other than Heartbleed, I think I've only revoked one certificate in the last 10 years or so. Amortized over that timeframe, the costs are negligible. That said, I would like it if StartSSL would offer free revocations in the case of something like Heartbleed, where certs are compromised through no fault of the customer, but I understand the business reasons for not doing so (CRL/OCSP isn't free).
Of course, I've abandoned several certs where I deleted a VM hosting a site I no longer needed, but since the cert was not compromised and the private key was deleted, I just let the expiration timer run out. No big deal.
To clarify I fully understand why startSSL do this, they are a buisness and they need to make money and they are certainly the best value widely recognised CA I have found.
I just don't think using startSSLs limited free certs as a rebuttal to claims that SSL increases costs for website operators is reasonable. Either you pay to get the wildcard certs or you pay to get extra IPv4 addresses or some combination of the two.
Why not just use SNI? I have multiple SSL-enabled virtualhosts running on a single server, and other than Internet Explorer on Windows XP and Android 2.x (neither of which I care about, as the former is EOL while the latter is effectively EOL) every browser on desktop and mobile devices works properly. I spend more money every two weeks on caffeinated beverages than my entire annual budget for SSL certs, and I have more than most. My cert budget is dwarfed by hosting costs (which I pay regardless of SSL support or not).
If you don't care about those systems (and I don't), SNI is perfectly satisfactory. If you need to support those old systems for some reason, you're probably a commercial enterprise who can afford IP-based SSL or wildcard certs. For typical individuals or small/medium-sized organizations using SNI, adding SSL support to your sites will essentially be a non-issue in terms of cost.
If anything, Google adding a small boost to SSL-enabled sites should encourage and improve support for SNI and hopefully sweep away the few older browsers that don't support it. I'm all for it.
Gotta agree. My RT-N66U(Shibby 121) is running a crap load of stuff with zero downtime. VLAN, IPTV, VoIP, OpenVPN server and client, Print server, etc etc etc.
I've got an RT-AC68U as my access point. Not as mature firmware wise, and hard to test to it's full potential, but rock solid none the less.
ASUS can shut up and take my money.
Seconded in regards to the N66U. It's a fantastic router. I've been running Tomato Shibby for years (most recently v121) and it's been rock-solid, reliable, and stable.
There's only one downside: Tomato doesn't include the necessary kernel module for hardware accelerated WAN-to-LAN NAT/routing. This only matters if your downstream WAN bandwidth is greater than ~120Mbps. If your downstream bandwidth is less, the software routing can keep up and you'll run at full speed. If your downstream bandwidth is greater, you will be limited to ~120-130Mbps, as that's as fast as the N66U can route in software. LAN-to-LAN bandwidth will run entirely in hardware regardless of what firmware you have.
My ISP just upgraded me to a 250Mbps downstream link, so I reluctantly went back to the factory firmware to take advantage of the hardware acceleration. It's clunky and annoying compared to the elegance of the Tomato web interface, but it works. The Merlin firmware maintains the look-and-feel of the factory firmware, includes support for hardware acceleration, fixes a few bug and adds a few features (but not as many as Tomato) that makes it suck less.
I highly recommend the N66U.
2: they make the expiry artifically short (the CA industry as a whole does this but startSSLs free certs are epecially bad),
A validity time of one year is pretty standard for SSL certs (paid certs often charge per year). Could they issue them for 20 years? Sure, but a one year validity is not unusual. Class 2 certs are good for two years.
3: they refuse to renew certs until just before they expire and refuse to reissue certs without revoking the old one.
I get renewal notices two weeks prior to expiration. That's pretty reasonable. If I recall correctly, I can generate a new cert for my site any time in that two-week period, so I don't need to wait for the cert to expire before replacing it.
While I wish they allowed free reissuance of certs at any time, I don't really see why requiring revocation is a showstopper.
4: each free cert only covers a domain and one hostname under that domain (e.g. bar.com and foo.bar.com). This effectively means you end up needing one IP per hostname you want SSL on (until IE on XP becomes insignificant anyway).
That's also the case for pretty much any of the inexpensive paid certs too. You can always get a wildcard cert but most CAs charge at least $100/year for a single wildcard cert. StartSSL charges $60 for Class 2 validation, and you can issue unlimited certs (wildcard or not). Organizations can get Class 2 certified for $120 ($60 for identity verification, $60 for organization verification) and can issue unlimited certs. For a company needing more than one cert, StartSSL is still cheaper.
It's nice that there is a free (as in beer) option for some people but it's also clearly got a number of artificial restrictions on it to push people towards their paid options.
Considering their paid certs are often cheaper than comparable offerings from other CAs, it doesn't really seem unreasonable to me. Doubly so because they're run by competent people who respond promptly to inquiries, even from free users. I've been a StartSSL customer for years (and also used other CAs like GoDaddy, Comodo, Thawte, etc.) and the customer service from StartSSL has always been excellent.
If you don't want to get a StartSSL cert or they don't meet your needs, that's fine. NameCheap and others sell single-domain Comodo certs for $9/year. RapidSSL certs are a buck or two more per year. That costs less than a single beer at the local bar. Hardly a massive expense.
Quite the contrary: StartSSL is accepted by every major browser and SSL/TLS library, and has been for years.
Well-known sites, like EFF.org, LibreOffice, and others use StartSSL-issued certs and don't have any issues. Sure, they're not Google-sized sites, but they're fairly major.
That doesn't jive with my results though. At work, if I'm in the building in the center all day without appreciable service my phone doesn't last the day. If I'm at an outside wall, my phone barely makes it through the day without any significant usage, barely getting one bar. If I'm out and about I've had service work on standby for couple of days when I've forgotten to charge it overnight.
That seems to match with what I'm saying: when the phone is constantly searching for signals it has the receiver enabled all the time and the gain turned up to maximum, using more power. When it is in an area of low-but-there signal, the receiver isn't powered up as often, but the gain is still high, so it uses a medium amount of power. When you're out in the open and there's lots of signal, the receiver isn't powered up as often and the gain is low, so it uses the least amount of power.
I apologize if I wasn't clear before.
Usually, a terrestrial phone doesn't need to do anything much to "look" for a tower, besides keeping its receiver turned on. Towers emit beacons, and if you don't hear the beacon, there's no point in you sending anything - you won't receive a reply because you don't even hear the tower's beacon.
Indeed, many (most? all?) phones won't transmit at all unless they hear the tower's beacon, since it's possible they could have been moved to a jurisdiction where it is not allowed for them to transmit on certain frequencies they would otherwise use.
Of course, keeping the receiver powered to listen for the beacon does use a not-inconsiderable amount of power, so searching for signal will use more power than a phone that is connected to the network and idle.
If the keys are stored on the box in any way then they are compromised because the box is. The synology box is rooted, any information stored on that box is compromised. If for example your root key for S3 is backed up on the NAS then it's compromised.
Agreed. That's why you shouldn't use the root S3 access key for anything (in fact, don't generate one at all). Use service-limited, least-access keys for AWS accounts: there's no reason a NAS should have an access key capable of creating EC2 instances. It should have list+write access only to S3 (and/or Glacier). If users want to delete files from S3, they should have to log in with a different user (perhaps to the AWS console) and specifically do that.
Amazon provides good options in this regard, and it's too bad if users aren't taking advantage of them.
People are glossing over this, if the box is rooted everything it knows and stores is compromised, that's how people need to be analyzing this instead of blowing it off as no big deal.
In this specific case, the malware does not seem to want to steal user data, only to encrypt it and ransom it back to users. Sure, it could steal data, but it doesn't seem to do so. It's a big deal to those who are unprepared and don't have proper backups, but it could definitely be worse.
You do realize that for the S3 backup to work Synology or the NAS (and the NAS has you Synology login info) has your login information for S3, and that if this thing is owning the NAS there is a pretty damn good chance the malware has owned your S3 instance as well right? The only way it wouldn't is if the S3 backup is totally manual.
Amazon has a very extensive authentication system -- you can easily configure the Synology with an S3 access key that only has "List Files" and "Upload Files" permissions, but not "Delete Files" or "Overwrite Files". This way, even if the Synology box gets owned or a user fat-fingers something, the files on S3 aren't at risk. You don't (and shouldn't) need to use your AWS root access keys for S3.
I have a similar setup with Amazon's Glacier: my standard access key has only list, upload, and retrieve permissions. A separate access key is required to delete files (I've configured my Glacier client, FastGlacier, to prompt me for a password when I switch to the "delete" key) so that I don't accidentally end up deleting important backups.
You do have backups, right?
I'd like something like this for a mixed Windows/Mac/Linux network but the costs are just prohibitive.
Yubikeys are $25 each for the hardware, and $45 PER USER. That's just ridiculous when you scale up, and there's an awful lot of manually faffing about to get to the point that it works.
Wait, what? Where do you get the $45 per user cost? I don't see that anywhere on their website.
The "YubiCloud" (where Yubico hosts the authenticator servers) has two modes: free and premium. The free service is open to everyone, even commercial users. The premium service offers an SLA and monthly usage statistics, and costs $3/YubiKey/year (1000-unit minimum).
You can also host your own local YubiKey authentication servers and keep things entirely in-house. Yubico has reference implementations for free on their site.
For software tokens, Google Authenticator has apps for Android, iOS, and BlackBerry. They implement the TOTP standard, so any compatible code-generating software (such as the J2ME app I have on my non-smartphone) will work with it.
They also have a PAM module that works with SSH (or anything else that uses PAM). I've used it before, and it works great.
For reference, neither the apps nor the PAM module depend in any way on Google services, they don't send any data to Google, and will work perfectly happily in a totally offline environment (assuming all the servers and client apps have synchronized clocks).
I don't know about gigabit, but Steam has no problems maxing out my 150Mbps downstream link when I'm downloading games from a nearby server here in Switzerland.
The NRA has its deep pockets and resultant clout not (necessarily) from numerous individual private members but from effectively being an arms industry trade group, the USCoC of arms manufacturers and dealers.
The NSSF is the arms industry trade group. The private arms industry in the US is relatively small compared to, say, the oil, tobacco, alcohol, etc. industry and doesn't have anywhere near the same political clout as those industries. The largest source of income for the NRA is membership dues, and it's from their 5+ million members that they derive their political clout.
Nothing unfortunate about it. That only affects the rich and powerful who for all purpose defraud american taxpayers and then shift the money offshore.
Why should any american have to suffer increased deficits and taxes so a tiny elite of wealthy parasites can continue to leach american money offshore
It also affects ordinary, non-rich-and-powerful people like myself: I'm an American PhD student in Switzerland and dealing with all the tax laws purportedly targeted at shady rich people (but which overwhelmingly affect ordinary people) is a massive pain and costs my wife and I several hundred dollars per year for a tax accountant to do our reasonably straightforward (i.e. we have some US investments, retirement accounts, etc. but earn all of our income in Switzerland) taxes.
Honestly, the whole thing can be resolved by making US tax law similar to that elsewhere in the world: pretty much all the other countries tax people based on their residency, not citizenship. That is, a Canadian living in Canada will pay Canadian taxes, but a Canadian living in Switzerland only pays Swiss taxes and owes the Canadian government nothing. Americans get taxed on their global income even if they don't live in the US (though there is a certain amount below which they're not double-taxed).
I have a DPScope and rather like it.
It's not a super advanced scope, and doesn't compare to standalone scopes like the Rigol DS1052E, but for someone on a budget who has fairly basic needs, it's worth a shot. It was developed by a guy who was annoyed at the drawbacks of other PC-based oscilloscopes and their software.
I use mine for testing homebuilt electronics, and it does well for that. I wouldn't use it for anything significantly more than that sort of stuff, though.
Planes get lost, re-routed etc ALL the time.
Think a nightclub with laser advertising, plane flies overhead, or helicopter.
Can they be punished?
Major astronomical telescopes often use lasers for their adaptive optics systems. They coordinate with relevant authorities to insure they don't zap sensitive optics on satellites and post "plane spotters" outside so they can shut down the laser if a plane comes too close to the beam.
Of course, those lasers tend to be considerably more powerful (>5W) than handheld laser pointers (~5mW), so it might not be directly comparable, but I'd hope that any organization that is shooting lasers into the sky would have someone keeping an eye out for aircraft.
To have guns insured just like cars are, so that gun owners will always have enough funds to cover any damages that may ensue from mishandling the weapon.
If gun insurance coverage was mandatory then there'd be the right framework for a proper marketplace dynamics.
That's called "liability insurance" and is already included in typical homeowners and renters insurance policies -- the liability policy applies to incidents both on and off one's property. Pretty much everyone already has this (or should have it). It's quite inexpensive, and is typically less than $200/year for renters, so it seems that insurance companies have very little worries about gun owners.
That said, your analogy to car insurance doesn't make sense: the vast majority of car-related injuries and death are due to unintentional acts (i.e., accidents), which insurance will cover. The majority of gun-related injuries and deaths are due to intentional criminal acts, which insurance definitely will not cover. Those likely to go about committing criminal acts with their firearms are unlikely to have "gun insurance" anyway, regardless of if it's legally mandated or not. Your typical gun owner already has liability insurance through their homeowners or renters insurance.
Try turning off a car with keys when the car is in drive.
Mostly doesn't work.
Always worked for me in various cars including a 1982 Volvo 240DL, a 1992 Mercedes 300D turbodiesel, a 2003 Honda Insight, and a 2006 Toyota Camry.
For clarity, I had tested these vehicles in a controlled manner, not an emergency situation nor on public roads.
Unfortunately they were incorrect.