Yo should look a little deeper. A) Guns are seriously regulated, including need to account for every round. Good luck getting the level of regulation about firearm in the US.
Not quite. You need to account for every round purchased at the range because the government subsidizes such ammo, even for practice purposes with non-government-issued firearms.
You can buy unsubsidized sporting ammo from gun shops and gun-related sporting goods shops with essentially no restrictions other than having the fact that you've bought ammo recorded in a logbook at the shop (which is the case for a small number of US states).
The Swiss do require a permit to purchase guns from a commercial shop, but this is automatically issued unless one is disqualified from owning arms (e.g. mentally unfit, convicted criminal, etc.). Purchasing single-shot or bolt-action firearms does not require a permit. Private sales do not require a permit, but buyer and seller need to keep a record of sale for 10 years.
So not only do those of us responsible for web servers need to generate new server certs for all of our servers... pretty much every current web server cert in existence also needs to be revoked. Are the CAs even willing/able to do something on that scale in a short amount of time?
Obviously, the CAs don't really have a choice in the matter, but I can't imagine they really have capacity issues in regards to the actual revoking/signing as that's all automated. If things get crazy busy, they can always queue things -- for most admins it doesn't really matter if the new cert is issued immediately or after 15 minutes.
Human-verified certs like org-verified and EV certs might have a bit of delays, but domain-validated certs should be quick to reissue.
Of course, revocation checking for browsers is really bad. Ideally, all browsers would handle revocation checking in real-time using OCSP and all servers would have OCSP stapling enabled (this way the number of OCSP checks scales as the number of certs issued, not the number of end-users). Stapling would help reduce load on CA OCSP servers and enable certs to be verified even if one is using a network that blocks OCSP queries (e.g. you connect to a WiFi hotspot with an HTTPS-enabled captive portal that blocks internet traffic until you authenticate; without stapling there'd be no way to check the revocation status of the portal).
Also, browsers should treat an OCSP failure as a show-stopper (though with the option for advanced users to continue anyway, similar to what happens with self-signed certificates).
Sadly, that's basically the opposite of how things work now. Hopefully things will change in response to Heartbleed.
Personally, I think that it should be law that if you buy shares in any company (or fund or whatever), you have to hold on to them for a minimum of a week or a month. Shares represent actual physical companies which own factories and employ real people. Those things don't change in 500 ms. They change over a much larger amount of time. And I believe that the stock market would be healthier if this was reflected in its trading. Obviously, when new information comes out (press release: "The factory of company X has just gone up in flames"), everybody's counter should be set to zero, but shares sold in such a case cannot be bought back a fraction of a second later (because whoever just bought them has to hold on to them for a week/month).
A week or a month might be a bit too long, but something along the order of 1-5 minutes might be reasonable.
Alternatively, one might also have the exchange do batch orders: traders submit their orders to the exchange, the exchange groups them all together, and then processes them all periodically (say, every 30 seconds or something), then displays the results. Since the results are not released until after the batch is fully processed there's no advantage to submitting an order at 29.999 seconds compared to any other time within that window. This way trades can be executed reasonably quickly on a human scale and HFT doesn't have any particular advantage.
What's with the "cloudflare" website middleman stuff? Kind of feels like someone's breaking net neutrality. I can't read the link unless I go through a middleman SSL & whatnot?
Cloudflare's basically a CDN.
The site owner intentionally uses Cloudflare as a middleman to cache their content in locations around the globe and to improve security (Cloudflare can block attacks before they hit the actual server). Cloudflare also offers SSL proxying to site owners so visitors can connect securely to the local Cloudflare cache, which in turn connects securely to the source server.
It's quite similar to, say, Akamai, and doesn't "break net neturality" (the site owner specifically elects to use Cloudflare, just as they'd elect to use Akamai).
with dozens of satellites in orbit and then no ISP subscription needed, FREE internets for everybody with an internet capable device, smartphone, tablet, laptop, desktop, etc...
that would make ALL ISPs obsolete
Who pays for the launches, the satellites and the constant adjustments needed to keep them in proper orbits, the ground stations, and the staff needed to run everything? Those are hardly free.
At the very start he turned over all his data to a few journalists (Glenn Greenwald, Laura Poitras, etc.) and they are the ones who choose to publish articles based on the data he gave to them. Snowden has said he doesn't retain any of the documents or data himself, and has no control over what is published or not. That's entirely up to the journalists.
How come it made into the news now but not at that time?
Two years is a long time. It seems it is the time it takes to a non-professional to tamper with a video, after the guy got the idea that the video would be more fun having a meteorite falling along with him. Seriously, a falling meteorite? Even if the camera would have caught a real meteorite, we'd have seen a blurry line, at best. The images breakdown clearly shows a number of photographs that have been added to the video.
If the meteorite and the skydiver were moving at (or near) their respective terminal velocities, why do you think that you'd see only a blurry line? The meteorite is not traveling at orbital velocities that deep into the atmosphere (or else it'd be glowing).
Article notes that they kept it quiet so the geologists could have a look for the rock - I assume these things are pretty rare and perhaps there's even a concern a treasure hunter might get there first and take it? (perhaps a geologist can give a more informed opinion here....) . Certainly I have a geologist friend who was flown from Europe to the deserts of Australia on more than one occasion to look for meteorites because they are so rare... apparently much easier (comparatively speaking) to spot in a bare desert than lush green European landscapes.
The article suggests they looked for it, couldn't find it, and are now asking the public to help find it. Plus perhaps it took a while before the sky diver realised something had happened after a few views of the footage, he might not have realised at the time.
I'm not a geologist, but I do research on meteorites and have participated in a meteorite search expedition sponsored by the Swiss and Omani governments. You're right: there is a concern that private collectors might find meteorites first. In the case of the expedition I was on, that was a major concern: we were plotting the distribution of thousands of fragments of one meteorite strewn over a large (several hundred square kilometers) area. Each of the fragments we found were photographed where they lay from several angles, the location recorded using GPS, given a catalog number, collected using clean tools etc. Private collectors often don't bother doing this, so it makes it difficult to identify where meteorites in private collections came from. This makes it difficult for researchers who are interested in the precise distribution of the fragments (some of my colleagues are able to use the distribution of light and heavy fragments from this meteorite to determine the speed of the wind at different altitudes when the meteorite passed through the atmosphere, and this requires precise knowledge of where the fragments were found). My particular research is less concerned with location, but it's still nice to know the provenance of meteorites.
Of course, we don't begrudge individuals finding meteorites and wanting to keep or sell them, but we'd really appreciate it if people called their local university (or other relevant authority) so researchers could log the find and perhaps keep a sample for scientific purposes.
I know not everyone is able to set up their OwnCloud server. There are places that will host it and set it up for you.
OwnCloud is great, with one exception: the slightest change to a file necessitates an upload of the entire file. Dropbox does delta syncs using a modified version of rsync, so it only uploads change portions of a file.
For typical files and fast connections, the lack of delta sync is tolerable, but when you're dealing with large files or slower transfer speeds it's an issue: if you, for example, you keep a large TrueCrypt container file in OwnCloud and make a change to a small file stored in the container, OwnCloud needs to reupload the entire container. Dropbox would just update the blocks that changed.
Until OwnCloud implements some sort of delta sync functionality it is considerably less practical than Dropbox.
I believe it was Thawte did/do free certs for email for non-commercial use. I would prefer php/gpg though.
Edit: did. Ah well.
(Just kidding, Slashdot has no edit function)
CAcert.org and StartSSL offer free client certs.
While CAcert's root is not included in browsers and mail clients (thus people you communicate with will need to install and trust the CAcert root or they'll get scary warnings), the StartSSL root is widely included. StartSSL is totally free for "Class 1" certs (domain-validated server certs or email-validated client certs) for non-commercial purposes. Class 2 certs (identity-validated server and client certs, as well as organization-validated certs for organizations) only charge money for the validation, but you can issue as many certs as you want for yourself (or your organization, if you get the org certs) at no extra cost.
My question is this voluntary? How is exactly does one opt out if they prefer traditional care? Doesn't seem to be like a recent victim of gross trauma, can exactly make an informed decision.
Getting this technique into hospitals hasn't been easy. Because the trial will happen during a medical emergency, neither the patient nor their family can give consent. The trial can only go ahead because the US Food and Drug Administration considers it to be exempt from informed consent. That's because it will involve people whose injuries are likely to be fatal and there is no alternative treatment. The team had to have discussions with groups in the community and place adverts in newspapers describing the trial. People can opt out online. So far, nobody has.
The article briefly mentions this, but does anyone have any additional detail? Are they using opportunistic TLS on SMTP connections?
Yes.
Depending on what ciphers are supported by the remote system, different ciphersuites will be supported. CheckTLS.com will only connect with RC4-SHA, but my server connects with ECDHE-RSA-AES128-GCM-SHA256. Your mileage may vary.
traffic over SSL connections is not encrypted using public key cryptography. the certificate is only used to assert there is no man in the middle during key exchange. The data is encrypted with the randomly generated keys exchanged during the SSL handshake.
Your statement is true if and only if both sides of the connection use Perfect Forward Secrecy.
If PFS is not supported by one or both sides, they revert to RSA key exchange which does use the server's RSA key to encrypt the session key. If the server's private key is compromised any non-PFS traffic that was logged in the past could be decrypted.
The AC above says that the connection between checktls.com and Gmail is made using RC4-SHA -- in that case, no Perfect Forward Secrecy is being used and the connection could be decrypted later if the server's private key was compromised.
In the case of my server connecting to Gmail, the connection is secured with ECDHE-RSA-AES128-GCM-SHA256 -- the ECDHE indicates that it uses elliptic curve-based ephemeral Diffie-Hellman key exchange, which does have PFS.
Perhaps shockingly, most secure sites on the internet don't have PFS enabled or, if they do, don't set them as a high priority. See https://www.trustworthyinterne...">here for details: 42% of sites have PFS enabled, but only 5.6% are configured so that PFS will be used by browsers (the rest have them set as a lower-priority).
That depends on the cipher preferences of the client (that is, the system sending mail to Gmail). In my case, connections from my server to Gmail's SMTP servers are made using ECDHE-RSA-AES128-GCM-SHA256.
Connections from other services depend on how they're configured. Geocaching.com's outgoing mail server sends mail to Gmail using ECDHE-RSA-RC4-SHA.
Google has their own intermediate CA, which is a subsidiary of GeoTrust. Given that such an intermediate could issue certs for the global internet, GeoTrust probable provides a "managed PKI" service where they retain control of the intermediate so that it will only issue certs for Google-controlled domains.
In such a situation, GeoTrust could be compelled to issue certs using Google's intermediate CA without Google's knowledge.
Alternatively, if Google maintained control of the intermediate, the NSA would need to compel Google to generate certs for them from their own intermediate. However, if the NSA went to GeoTrust and demanded that they generate an intermediate CA with all the same details (CN, O, OU, etc.) as the Google one, the NSA could generate certs for Google without Google knowing.
I do not know the particulars there. IMO, if Netflix expects ISPs to pay for their CDN, they are on drugs.
All the peering details are here. In short: they don't charge anything. They offer direct interconnects to Netflix's CDN for free, free peering at major internet exchange points, and free, Netflix-managed hardware caches to ISPs to avoid duplicate network traffic (the vast majority of traffic stays within the ISPs internal network). For the hardware caches the ISP needs only provide power and network connectivity.
There's really no reason for ISPs to wrangle with Netflix -- there's plenty of options to avoid congestion.
Over the last month or so I've really been into Deus Ex: Human Revolution. I've been a huge fan of the original Deus Ex (and, to a lesser extent, Deus Ex: Invisible War) and still go back and play it about once a year.
DX:HR is a worthy successor to the original.
I'm also a big fan of the Mass Effect and Fallout series. I'm working my way through the Fallout:New Vegas DLC (in the middle of Old World Blues, having finished Lonesome Road and the main game itself), though I really prefer Fallout 3 over NV.
After finished the NV DLC I'm looking at Skyrim, though the fact that I'm working on a PhD and my wife and I are expecting a daughter in mid-June might cut into my Copious Free Time.
Its all time based. You get you your first sms from google, and that sets up the sequence of numbers that are calculated based on that seed and the current time. I if have two phones, or move your Sim to a different phone, you have to set that up as well. But the weird thing is both phones will show different sequences, but either sequence will work to authenticate.
But use your friend's phone, it won't work. So it sounds to me that Google is keeping one timer for each authorized phone for your google account. So I thinks they CAN know which device you authenticate with.
You're partially right: Google's two-factor authentication service has two independent means of authenticating you: 1. You enter a code produced by the code generating app. 2a. They send an SMS to a phone number you've registered with them ahead of time, and you enter the code. 2b. They call a phone number you've registered with them ahead of time and a text-to-speech robot reads you a code, which you enter.
Mode #1 does not require (and in fact cannot use) SMS to setup -- rather, they show you a QR code containing the needed configuration information (e.g. the shared secret and some descriptive text). You use the Google Authenticator (or other OATH-TOTP compatible app) to take a picture of the QR code, thus configuring your code generating app. If your app does not support QR code reading, you can display the shared secret itself and manually enter it. At no time does the app ever send or receive any data over the network to/from Google. So long as you use the code generator, Google has no way of knowing which device you're using to authenticate. In my case, I have an iPod Touch, a Nexus 7 Android tablet, and a dumbphone with no data access that uses a third-party OATH-TOTP J2ME app to generate codes and they all produce the same codes as I've configured them all to use the same shared secret. Google cannot tell which one I'm using.
Google will only display the QR code/shared secret once -- you can configure as many devices as you want at that time by scanning the code/entering the secret and they'll all generate the same time-based code. However, if you ever go back to your Google Account settings and re-intialize the two-factor authentication it will generate a new secret and show a new QR code. When this happens the old shared secret is disabled and is no longer valid for authenticating to your account (this gives you the ability to revoke the code generator on a lost or stolen phone).
Put simply: there is only a single TOTP secret for your account. Changing the secret revokes the old one.
Naturally, if you use the SMS/voice call system they will know what device you've used to authenticate, but that doesn't apply to the code generator.
The scary warnings in browsers aren't likely to go away anytime soon, so I doubt that any webmaster of a website meant for public use is going to be using self-signed certs (other than those catering to specific, tech-savvy audiences).
Tech-savvy audiences are ok with self-signed certs?
Some, sure.
Note how I used "specific". That word was used for a reason.
There may be, for example, a community of crypto-savvy users who would rather not rely on a third-party CA to authenticate their certs. A site administrator could issue a self-signed certificate for the community site and post the PGP-signed details (e.g. fingerprint, key length, etc.) of the certificate so that members could verify its authenticity.
Other sites, like the anti-spam DNSBL named SORBS, use certs issued by their own internal CA. Users of that site may well trust the CA to issue such certs.
Self-signed certs have their uses, but are not really suitable for secure sites intended to be used by the general public.
In short: a site can declare that it only uses one (or more) public keys on its secure sites and that this declaration is valid for a certain time period. Browsers that support pinning will check to see if those public keys (and no others) are being used during that validity period. If the key were to suddenly change, even if it's otherwise valid (e.g. issued by a trusted CA), the browser would complain that something is wrong.
This prevents rogue or compromised CAs from issuing certificates to sites that used pinned certificates (at least for the duration of the validity period).
For example, Google Chrome comes hard-coded with the public keys for Google sites. If an otherwise-valid certificate were created for Google sites (such as when the DigiNotar CA was compromised), Chrome would refuse to connect to any server using it because it does not match the built-in pinned value.
1)Not all content is provided over both HTTP and HTTPS. For multiple reasons, one being performance. Which leads us to the second problem...
True, which is why HTTPS Everywhere only enables HTTPS on sites that support it (they are specifically whitelisted by the extension devs).
2)A HTTPS session incurs a significant overhead for encryption. Which may be no problem for someone like Google. But for someone hosting his/her own (moderately successful) website on a small server, it might just overload said server.
While HTTPS does incur some overhead, it's surprisingly small for modern servers. Google, for example, was able to add SSL/TLS to all Gmail connections with no new hardware, no additional servers, and SSL/TLS accounts for only about 1% of their CPU time (see here for details).
Pretty much any server will reach other bottlenecks before the slight overhead of SSL/TLS becomes an issue. Using Perfect Forward Secrecy is important for security and using DHE-based ciphers do incur a moderate overhead compared to non-DHE ciphers (a factor of about 3). Using ECDHE instead makes the increase in overhead only about 15% rather than 300%. See here for details.
3)Quite possibly the biggest problem with HTTPS is the fact that users have been trained over many years to just click "accept/install certificate" on self-signed certs. Not knowing that if you do this you are no longer secure.
And the more we keep forcing HTTPS, the more webmasters will use self-signed certs. Not many people want to go through the hassle of obtaining (and maintaining!) a valid SSL certificate for every single website they run, even if that cert is free. Which will only exacerbate the problem...
[citation needed] Getting a domain-validated SSL cert from publicly-available CAs is the work of a few minutes and, as you point out, often available for free or very low cost. Many hosts will automate the generation of a private key and CSR, making the process one of copy-paste for the customer. Other hosts handle the entire process of generating a private key, getting it signed by a CA, and configuring things correctly.
Sure, some sites use self-signed certs, but these are usually for personal or internal corporate purposes and not for the general public. The scary warnings in browsers aren't likely to go away anytime soon, so I doubt that any webmaster of a website meant for public use is going to be using self-signed certs (other than those catering to specific, tech-savvy audiences).
So that Google can provide geolocation for devices without GPS by fingerprinting the signal strength patterns and access point names you see. They also use it for road traffic reports - where do you think Google Maps gets its traffic data from?
Exactly. When I activated a new Nexus tablet it explained in plain language about the Google Location Reporting (how they get data for the wifi geolocation you mention) and ask whether or not one wishes to activate it or not.
You can disable it in Settings --> Location --> Google Location Reporting. Turning GLR off does not interfere with other location-related things (for example, you can turn off GLR but still use the geolocation functions in Google Maps or other apps).
Slashdot Mirror
Yo should look a little deeper.
A) Guns are seriously regulated, including need to account for every round. Good luck getting the level of regulation about firearm in the US.
Not quite. You need to account for every round purchased at the range because the government subsidizes such ammo, even for practice purposes with non-government-issued firearms.
You can buy unsubsidized sporting ammo from gun shops and gun-related sporting goods shops with essentially no restrictions other than having the fact that you've bought ammo recorded in a logbook at the shop (which is the case for a small number of US states).
The Swiss do require a permit to purchase guns from a commercial shop, but this is automatically issued unless one is disqualified from owning arms (e.g. mentally unfit, convicted criminal, etc.). Purchasing single-shot or bolt-action firearms does not require a permit. Private sales do not require a permit, but buyer and seller need to keep a record of sale for 10 years.
Source: I live in Switzerland.
Keyfiles don't work for system encryption with TrueCrypt: you can only use passwords (or passphrases, of course).
So not only do those of us responsible for web servers need to generate new server certs for all of our servers... pretty much every current web server cert in existence also needs to be revoked. Are the CAs even willing/able to do something on that scale in a short amount of time?
Netcraft actually has an interesting article about that very situation.
Obviously, the CAs don't really have a choice in the matter, but I can't imagine they really have capacity issues in regards to the actual revoking/signing as that's all automated. If things get crazy busy, they can always queue things -- for most admins it doesn't really matter if the new cert is issued immediately or after 15 minutes.
Human-verified certs like org-verified and EV certs might have a bit of delays, but domain-validated certs should be quick to reissue.
Of course, revocation checking for browsers is really bad. Ideally, all browsers would handle revocation checking in real-time using OCSP and all servers would have OCSP stapling enabled (this way the number of OCSP checks scales as the number of certs issued, not the number of end-users). Stapling would help reduce load on CA OCSP servers and enable certs to be verified even if one is using a network that blocks OCSP queries (e.g. you connect to a WiFi hotspot with an HTTPS-enabled captive portal that blocks internet traffic until you authenticate; without stapling there'd be no way to check the revocation status of the portal).
Also, browsers should treat an OCSP failure as a show-stopper (though with the option for advanced users to continue anyway, similar to what happens with self-signed certificates).
Sadly, that's basically the opposite of how things work now. Hopefully things will change in response to Heartbleed.
Personally, I think that it should be law that if you buy shares in any company (or fund or whatever), you have to hold on to them for a minimum of a week or a month. Shares represent actual physical companies which own factories and employ real people. Those things don't change in 500 ms. They change over a much larger amount of time. And I believe that the stock market would be healthier if this was reflected in its trading. Obviously, when new information comes out (press release: "The factory of company X has just gone up in flames"), everybody's counter should be set to zero, but shares sold in such a case cannot be bought back a fraction of a second later (because whoever just bought them has to hold on to them for a week/month).
A week or a month might be a bit too long, but something along the order of 1-5 minutes might be reasonable.
Alternatively, one might also have the exchange do batch orders: traders submit their orders to the exchange, the exchange groups them all together, and then processes them all periodically (say, every 30 seconds or something), then displays the results. Since the results are not released until after the batch is fully processed there's no advantage to submitting an order at 29.999 seconds compared to any other time within that window. This way trades can be executed reasonably quickly on a human scale and HFT doesn't have any particular advantage.
What's with the "cloudflare" website middleman stuff? Kind of feels like someone's breaking net neutrality. I can't read the link unless I go through a middleman SSL & whatnot?
Cloudflare's basically a CDN.
The site owner intentionally uses Cloudflare as a middleman to cache their content in locations around the globe and to improve security (Cloudflare can block attacks before they hit the actual server). Cloudflare also offers SSL proxying to site owners so visitors can connect securely to the local Cloudflare cache, which in turn connects securely to the source server.
It's quite similar to, say, Akamai, and doesn't "break net neturality" (the site owner specifically elects to use Cloudflare, just as they'd elect to use Akamai).
with dozens of satellites in orbit and then no ISP subscription needed, FREE internets for everybody with an internet capable device, smartphone, tablet, laptop, desktop, etc...
that would make ALL ISPs obsolete
Who pays for the launches, the satellites and the constant adjustments needed to keep them in proper orbits, the ground stations, and the staff needed to run everything? Those are hardly free.
Do I think he's lost legitimacy? No.
At the very start he turned over all his data to a few journalists (Glenn Greenwald, Laura Poitras, etc.) and they are the ones who choose to publish articles based on the data he gave to them. Snowden has said he doesn't retain any of the documents or data himself, and has no control over what is published or not. That's entirely up to the journalists.
How come it made into the news now but not at that time?
Two years is a long time. It seems it is the time it takes to a non-professional to tamper with a video, after the guy got the idea that the video would be more fun having a meteorite falling along with him. Seriously, a falling meteorite? Even if the camera would have caught a real meteorite, we'd have seen a blurry line, at best. The images breakdown clearly shows a number of photographs that have been added to the video.
If the meteorite and the skydiver were moving at (or near) their respective terminal velocities, why do you think that you'd see only a blurry line? The meteorite is not traveling at orbital velocities that deep into the atmosphere (or else it'd be glowing).
Article notes that they kept it quiet so the geologists could have a look for the rock - I assume these things are pretty rare and perhaps there's even a concern a treasure hunter might get there first and take it? (perhaps a geologist can give a more informed opinion here....) . Certainly I have a geologist friend who was flown from Europe to the deserts of Australia on more than one occasion to look for meteorites because they are so rare... apparently much easier (comparatively speaking) to spot in a bare desert than lush green European landscapes.
The article suggests they looked for it, couldn't find it, and are now asking the public to help find it. Plus perhaps it took a while before the sky diver realised something had happened after a few views of the footage, he might not have realised at the time.
I'm not a geologist, but I do research on meteorites and have participated in a meteorite search expedition sponsored by the Swiss and Omani governments. You're right: there is a concern that private collectors might find meteorites first. In the case of the expedition I was on, that was a major concern: we were plotting the distribution of thousands of fragments of one meteorite strewn over a large (several hundred square kilometers) area. Each of the fragments we found were photographed where they lay from several angles, the location recorded using GPS, given a catalog number, collected using clean tools etc. Private collectors often don't bother doing this, so it makes it difficult to identify where meteorites in private collections came from. This makes it difficult for researchers who are interested in the precise distribution of the fragments (some of my colleagues are able to use the distribution of light and heavy fragments from this meteorite to determine the speed of the wind at different altitudes when the meteorite passed through the atmosphere, and this requires precise knowledge of where the fragments were found). My particular research is less concerned with location, but it's still nice to know the provenance of meteorites.
Of course, we don't begrudge individuals finding meteorites and wanting to keep or sell them, but we'd really appreciate it if people called their local university (or other relevant authority) so researchers could log the find and perhaps keep a sample for scientific purposes.
Doesn't that mean every change you make/new file you add requires the entire container file to be re-uploaded?
No. Dropbox uses delta sync (they use a modified version of rsync): it will only upload the changed blocks, not the entire file.
This is what OwnCloud is made for.
I know not everyone is able to set up their OwnCloud server. There are places that will host it and set it up for you.
OwnCloud is great, with one exception: the slightest change to a file necessitates an upload of the entire file. Dropbox does delta syncs using a modified version of rsync, so it only uploads change portions of a file.
For typical files and fast connections, the lack of delta sync is tolerable, but when you're dealing with large files or slower transfer speeds it's an issue: if you, for example, you keep a large TrueCrypt container file in OwnCloud and make a change to a small file stored in the container, OwnCloud needs to reupload the entire container. Dropbox would just update the blocks that changed.
Until OwnCloud implements some sort of delta sync functionality it is considerably less practical than Dropbox.
I believe it was Thawte did/do free certs for email for non-commercial use. I would prefer php/gpg though.
Edit: did. Ah well.
(Just kidding, Slashdot has no edit function)
CAcert.org and StartSSL offer free client certs.
While CAcert's root is not included in browsers and mail clients (thus people you communicate with will need to install and trust the CAcert root or they'll get scary warnings), the StartSSL root is widely included. StartSSL is totally free for "Class 1" certs (domain-validated server certs or email-validated client certs) for non-commercial purposes. Class 2 certs (identity-validated server and client certs, as well as organization-validated certs for organizations) only charge money for the validation, but you can issue as many certs as you want for yourself (or your organization, if you get the org certs) at no extra cost.
My question is this voluntary? How is exactly does one opt out if they prefer traditional care? Doesn't seem to be like a recent victim of gross trauma, can exactly make an informed decision.
According to the article at New Scientist:
The article briefly mentions this, but does anyone have any additional detail? Are they using opportunistic TLS on SMTP connections?
Yes.
Depending on what ciphers are supported by the remote system, different ciphersuites will be supported. CheckTLS.com will only connect with RC4-SHA, but my server connects with ECDHE-RSA-AES128-GCM-SHA256. Your mileage may vary.
traffic over SSL connections is not encrypted using public key cryptography.
the certificate is only used to assert there is no man in the middle during key exchange. The data is encrypted with the randomly generated keys exchanged during the SSL handshake.
Your statement is true if and only if both sides of the connection use Perfect Forward Secrecy.
If PFS is not supported by one or both sides, they revert to RSA key exchange which does use the server's RSA key to encrypt the session key. If the server's private key is compromised any non-PFS traffic that was logged in the past could be decrypted.
The AC above says that the connection between checktls.com and Gmail is made using RC4-SHA -- in that case, no Perfect Forward Secrecy is being used and the connection could be decrypted later if the server's private key was compromised.
In the case of my server connecting to Gmail, the connection is secured with ECDHE-RSA-AES128-GCM-SHA256 -- the ECDHE indicates that it uses elliptic curve-based ephemeral Diffie-Hellman key exchange, which does have PFS.
Perhaps shockingly, most secure sites on the internet don't have PFS enabled or, if they do, don't set them as a high priority. See https://www.trustworthyinterne...">here for details: 42% of sites have PFS enabled, but only 5.6% are configured so that PFS will be used by browsers (the rest have them set as a lower-priority).
That depends on the cipher preferences of the client (that is, the system sending mail to Gmail). In my case, connections from my server to Gmail's SMTP servers are made using ECDHE-RSA-AES128-GCM-SHA256.
Connections from other services depend on how they're configured. Geocaching.com's outgoing mail server sends mail to Gmail using ECDHE-RSA-RC4-SHA.
Google has their own intermediate CA, which is a subsidiary of GeoTrust. Given that such an intermediate could issue certs for the global internet, GeoTrust probable provides a "managed PKI" service where they retain control of the intermediate so that it will only issue certs for Google-controlled domains.
In such a situation, GeoTrust could be compelled to issue certs using Google's intermediate CA without Google's knowledge.
Alternatively, if Google maintained control of the intermediate, the NSA would need to compel Google to generate certs for them from their own intermediate. However, if the NSA went to GeoTrust and demanded that they generate an intermediate CA with all the same details (CN, O, OU, etc.) as the Google one, the NSA could generate certs for Google without Google knowing.
Actually, the NRA is involved and has joined with the EFF, ACLU, and other groups in opposing NSA snooping.
I do not know the particulars there. IMO, if Netflix expects ISPs to pay for their CDN, they are on drugs.
All the peering details are here. In short: they don't charge anything. They offer direct interconnects to Netflix's CDN for free, free peering at major internet exchange points, and free, Netflix-managed hardware caches to ISPs to avoid duplicate network traffic (the vast majority of traffic stays within the ISPs internal network). For the hardware caches the ISP needs only provide power and network connectivity.
There's really no reason for ISPs to wrangle with Netflix -- there's plenty of options to avoid congestion.
Over the last month or so I've really been into Deus Ex: Human Revolution. I've been a huge fan of the original Deus Ex (and, to a lesser extent, Deus Ex: Invisible War) and still go back and play it about once a year.
DX:HR is a worthy successor to the original.
I'm also a big fan of the Mass Effect and Fallout series. I'm working my way through the Fallout:New Vegas DLC (in the middle of Old World Blues, having finished Lonesome Road and the main game itself), though I really prefer Fallout 3 over NV.
After finished the NV DLC I'm looking at Skyrim, though the fact that I'm working on a PhD and my wife and I are expecting a daughter in mid-June might cut into my Copious Free Time.
Its all time based. You get you your first sms from google, and that sets up the sequence of numbers that are calculated based on that seed and the current time.
I if have two phones, or move your Sim to a different phone, you have to set that up as well. But the weird thing is both phones will show different sequences, but either sequence will work to authenticate.
But use your friend's phone, it won't work. So it sounds to me that Google is keeping one timer for each authorized phone for your google account. So I thinks they CAN know which device you authenticate with.
You're partially right: Google's two-factor authentication service has two independent means of authenticating you:
1. You enter a code produced by the code generating app.
2a. They send an SMS to a phone number you've registered with them ahead of time, and you enter the code.
2b. They call a phone number you've registered with them ahead of time and a text-to-speech robot reads you a code, which you enter.
Mode #1 does not require (and in fact cannot use) SMS to setup -- rather, they show you a QR code containing the needed configuration information (e.g. the shared secret and some descriptive text). You use the Google Authenticator (or other OATH-TOTP compatible app) to take a picture of the QR code, thus configuring your code generating app. If your app does not support QR code reading, you can display the shared secret itself and manually enter it. At no time does the app ever send or receive any data over the network to/from Google. So long as you use the code generator, Google has no way of knowing which device you're using to authenticate. In my case, I have an iPod Touch, a Nexus 7 Android tablet, and a dumbphone with no data access that uses a third-party OATH-TOTP J2ME app to generate codes and they all produce the same codes as I've configured them all to use the same shared secret. Google cannot tell which one I'm using.
Google will only display the QR code/shared secret once -- you can configure as many devices as you want at that time by scanning the code/entering the secret and they'll all generate the same time-based code. However, if you ever go back to your Google Account settings and re-intialize the two-factor authentication it will generate a new secret and show a new QR code. When this happens the old shared secret is disabled and is no longer valid for authenticating to your account (this gives you the ability to revoke the code generator on a lost or stolen phone).
Put simply: there is only a single TOTP secret for your account. Changing the secret revokes the old one.
Naturally, if you use the SMS/voice call system they will know what device you've used to authenticate, but that doesn't apply to the code generator.
The scary warnings in browsers aren't likely to go away anytime soon, so I doubt that any webmaster of a website meant for public use is going to be using self-signed certs (other than those catering to specific, tech-savvy audiences).
Tech-savvy audiences are ok with self-signed certs?
Some, sure.
Note how I used "specific". That word was used for a reason.
There may be, for example, a community of crypto-savvy users who would rather not rely on a third-party CA to authenticate their certs. A site administrator could issue a self-signed certificate for the community site and post the PGP-signed details (e.g. fingerprint, key length, etc.) of the certificate so that members could verify its authenticity.
Other sites, like the anti-spam DNSBL named SORBS, use certs issued by their own internal CA. Users of that site may well trust the CA to issue such certs.
Self-signed certs have their uses, but are not really suitable for secure sites intended to be used by the general public.
See http://security.stackexchange.... and https://www.owasp.org/index.ph...
In short: a site can declare that it only uses one (or more) public keys on its secure sites and that this declaration is valid for a certain time period. Browsers that support pinning will check to see if those public keys (and no others) are being used during that validity period. If the key were to suddenly change, even if it's otherwise valid (e.g. issued by a trusted CA), the browser would complain that something is wrong.
This prevents rogue or compromised CAs from issuing certificates to sites that used pinned certificates (at least for the duration of the validity period).
For example, Google Chrome comes hard-coded with the public keys for Google sites. If an otherwise-valid certificate were created for Google sites (such as when the DigiNotar CA was compromised), Chrome would refuse to connect to any server using it because it does not match the built-in pinned value.
I see a few problems with this approach:
1)Not all content is provided over both HTTP and HTTPS. For multiple reasons, one being performance. Which leads us to the second problem...
True, which is why HTTPS Everywhere only enables HTTPS on sites that support it (they are specifically whitelisted by the extension devs).
2)A HTTPS session incurs a significant overhead for encryption. Which may be no problem for someone like Google. But for someone hosting his/her own (moderately successful) website on a small server, it might just overload said server.
While HTTPS does incur some overhead, it's surprisingly small for modern servers. Google, for example, was able to add SSL/TLS to all Gmail connections with no new hardware, no additional servers, and SSL/TLS accounts for only about 1% of their CPU time (see here for details).
Pretty much any server will reach other bottlenecks before the slight overhead of SSL/TLS becomes an issue. Using Perfect Forward Secrecy is important for security and using DHE-based ciphers do incur a moderate overhead compared to non-DHE ciphers (a factor of about 3). Using ECDHE instead makes the increase in overhead only about 15% rather than 300%. See here for details.
3)Quite possibly the biggest problem with HTTPS is the fact that users have been trained over many years to just click "accept/install certificate" on self-signed certs. Not knowing that if you do this you are no longer secure.
And the more we keep forcing HTTPS, the more webmasters will use self-signed certs. Not many people want to go through the hassle of obtaining (and maintaining!) a valid SSL certificate for every single website they run, even if that cert is free. Which will only exacerbate the problem...
[citation needed] Getting a domain-validated SSL cert from publicly-available CAs is the work of a few minutes and, as you point out, often available for free or very low cost. Many hosts will automate the generation of a private key and CSR, making the process one of copy-paste for the customer. Other hosts handle the entire process of generating a private key, getting it signed by a CA, and configuring things correctly.
Sure, some sites use self-signed certs, but these are usually for personal or internal corporate purposes and not for the general public. The scary warnings in browsers aren't likely to go away anytime soon, so I doubt that any webmaster of a website meant for public use is going to be using self-signed certs (other than those catering to specific, tech-savvy audiences).
So that Google can provide geolocation for devices without GPS by fingerprinting the signal strength patterns and access point names you see. They also use it for road traffic reports - where do you think Google Maps gets its traffic data from?
Exactly. When I activated a new Nexus tablet it explained in plain language about the Google Location Reporting (how they get data for the wifi geolocation you mention) and ask whether or not one wishes to activate it or not.
You can disable it in Settings --> Location --> Google Location Reporting. Turning GLR off does not interfere with other location-related things (for example, you can turn off GLR but still use the geolocation functions in Google Maps or other apps).