The security aspect (in regards to revocation) of shorter keys is nice, but encouraging automation to make widespread HTTPS use easy is the whole point of Let's Encrypt. It shouldn't be a surprise that they set cert lifetimes to encourage automation.
Without automation, deploying secure sites is a pain: administrators have to go through tedious, error-prone manual work that the typical mom & pop business or individual website won't bother with. This maintains the status quo, with not many sites being secure.
With automation, the user who otherwise wouldn't deploy HTTPS simply clicks a button on their web host management interface and Presto!, their site has a cert. (Alternatively, HTTPS could be enabled by default for them, as it is with WordPress.com-hosted sites.) For more technical administrators, a simple command-line tool and a cronjob take care of things in seconds. Easy, and it promotes a more secure web.
There's nothing magical about 90 day certs, and the timing was chosen to be short enough to encourage automation while being long enough to allow for manual renewal if needed. Indeed, they even say, "Once automated renewal tools are widely deployed and working well, we may consider even shorter lifetimes." That's fine with me: it's no skin off my back if they start making certs only valid for a week or two, as a daily cronjob manages everything.
Of course, your mileage may vary and you have your preferences. That's totally fine -- I too use non-LE certs for some internal services where automation isn't really viable -- and nobody's forcing you to use their service. It's a free internet, after all, and there's other CAs to choose from.
I don't know of any one-stop-shop (certificate issuance and backup MX service are pretty orthogonal to each other), but there's plenty of CAs out there that will issue you certificates.
This Comodo reseller sells PositiveSSL certs for ~$5/year with a validity time up to 3 years. That's about as cheap as you can get. They also offer (for the next few weeks, at least) GeoTrust, Symantec, and Thawte certs, but the costs for those are higher and they'll stop selling them in December. Comodo offers free S/MIME certs that validate only your email address, as well as paid ones that validate your email and name (if it matters). The paid ones start at $12/year.
Of course, Let's Encrypt is a good option: the certs are free and you can run any of a multitude of ACME clients (or write your own) to validate your domain, generate the key (which is made by and stays on your system), request the certificate, and install the certificate. A simple cronjob handles renewals without any interaction from you. That makes life really easy. They don't do S/MIME certs, though.
It is so over the top to stop trusting them "for evermore" because of this that it makes me thing they're trying to corner the free SSL cert marker with Let's Encrypt.
To what end? Let's Encrypt has gotten some funding from Mozilla and others, but otherwise is a separate entity run by the ISRG.
Since they don't sell any certificates (they're all free of cost) and running the service ends up costing lots of money (about $3m/year, they say), what motive would they have for "corner[ing] the free SSL cert marke[t]"?
Nothing's preventing anyone else from starting a free CA.
You don't have to run their software (that is, the reference implementation) on your servers. There's plenty of other ACME clients, including short Bash scripts that don't require root and are relatively easy to audit. You could write your own, if you want.
The short expiration times for Let's Encrypt certs exist for two reasons: 1. Revoking certs is a pain. Yes, OCSP is a thing, but malicious actors that can control the network can block OCSP and force users to keep trusting revoked certificates up to their expiration time. Most browsers treat OCSP failures as a soft-fail. This is partially alleviated with OCSP stapling, but not many servers support it. By having short certificate lifetimes, the window of validity for a compromised certificate is smaller.
2. It encourages automation. Rather than certificate issuance (and renewal) being an unusual thing that one needs to do every 1-3 years, during which time one likely has forgotten the procedure and has to go through many manual steps, issuing and renewing certs becomes routine and something easily scriptable and handled by automation. This makes it easier for more sites to deploy HTTPS, and for hosts to enable it with easy, automated tools.
Of course, there's plenty of other CAs out there offering relatively inexpensive certificates with longer lifetimes if you wish. As you say, that's something you prefer. That's fine too: I use LE certs for most of my sites, but some long-lived ones from other CAs for others. It's nice having options.
Which goes to show you how leaking of telemetry info is one of the biggest problems with certs.
How so?
So I have a server on my local network. To enable https, it needs a cert and you click through a form to create a Lets Encrypt cert. BUT if you do that, then you've injected an outside body in the verification!
What do you mean? If you mean the server validates its identity to the certificate authority, then yes, that's true. That's the point.
Each time it contacts that to check the cert, its informing the certificate company that you are accessing your own server on your own network
Let's Encrypt intends that the certificate issuance process is automated, such as with a cronjob. Thus, if you do things right, the server will periodically re-validate your site with Let's Encrypt and renew certificates automatically. This is intended.
If you mean that clients will query the CA's OCSP servers to verify the validity of the certificate, yes, this is true and a minor privacy concern. Fortunately, all modern browsers and servers support OCSP stapling. The server can, with a few lines (or enabling an option in Certbot, the major Let's Encrypt client), handle the OCSP checking itself and "staple" a signed OCSP response to the normal secure handshake. The stapled response is valid for a short period of time (a few days) and the server will query the OCSP servers periodically to get a fresh response. This way, clients don't reveal their browsing habits to the CA and the CA requires less resources for their OCSP servers. Win-win for all. If you haven't already, turn on OCSP stapling on your server.
Of course, if a server doesn't support OCSP stapling, browsers will fall back to querying the CA's OCSP responders.
Firefox should handle self signed certificates better. It treats them as dodgy, but they are not.
How would the browser know they're not dodgy? They are, by definition, self-issued. Anyone, including a bad guy, can make a self-signed certificate saying they're anyone else. There's no in-band way of authenticating a self-signed certificate.
Sure, one can manually elect to trust a self-signed certificate if one knows what one's doing, but the typical user is not knowledgeable enough to do that securely.
A certificate authority injected between you and a known server represents an unwanted man-in-the-middle.
The CA is not a "man in the middle", in that they're not involved in the secure handshake at all. They simply are a third party vouching for the validity of the information contained in the certificate: "We verified that the administrator of www.example.com controls that site and requested a certificate."
CAs undergo stringent vetting and auditing to ensure they follow specific policies before they're trusted by browsers, as well as annual audits thereafter. Is it perfect? No. Have CAs made errors, been compromised, or acted poorly? Yes, and in many cases those CAs received the "death penalty" of having their trust revoked by browsers. Still, it's the least-bad system available that scales for the internet. If you can think of something better, by all means, implement it.
... Letsencrypt provided certificates that lasted longer than 90 days. Ridiculous. Make it one year at least. Please.
The process is intended to be automated, such as with a cronjob, and the short lifetime is intended to resolve issues relating to the general suckitude of revocation.
It's only "free" if you don't value your time (the certs expire every few months), or if you don't need an EV cert, or if you don't need a wildcard cert.
Let's Encrypt intends that the installation and maintenance (e.g. renewal) is automated. A simple daily cronjob checks if any Let's Encrypt certs on that system are in need of renewal and, if so, handles the validation, issuance, and installation of those certs completely automatically. If anything, it dramatically *saves* admin time.
The vast majority of sites don't need EV or wildcard certs, so Let's Encrypt is perfect for them.
All the permissions Signal requires are explained here. They all make sense in context, and many can be disabled without affecting normal use (e.g. location, calendar, camera, etc.).
To answer your question about SMS in particular, OWS says "Signal is capable of functioning as a complete replacement to your phone’s stock messaging application. In order to do this, it needs to be able to send and receive text messages (both SMS and MMS). You can also import your existing messages into Signal when it is first installed, and these permissions allow that database to be read as well."
That's all perfectly true, but how do you get the clients to trust the alternate root? Essentially all DNSSEC-capable resolvers come with the ICANN root being trusted. Essentially all the distribution channels are protected from tampering (e.g. package managers like apt, downloading binaries or source from the developer's website, etc. all use digital signatures, many use HTTPS, etc.).
Short of impractically-extreme measures (e.g. maintaining and mandating the use of software repos, mirrors, etc. that include the alternate root's key, mirroring the entire DNS tree with entries signed by the alternate root), even state-level attackers will have a tough time forcing clients to trust the alternate root key.
How exactly then will this work when one DNS server has a record for one Ip address and another points to another such as an anti Putin site?
DNSSEC.
Due to the nature of DNSSEC, so long as the root is trusted all DNSSEC-enabled domains (assuming they're part of a signed TLD) are protected from such forgeries.
A large-scale attacker could certainly setup their own DNS infrastructure that's essentially the same as the standard system but with some minor modifications to redirect specific domain names to systems they control, but this would cause DNSSEC failures (assuming the resolver supports DNSSEC).
Out of curiosity, does your setup provide per-user control over spam/not-spam? That is, can a user flag a false-negative as spam and a false-positive as not-spam so the filters can be automatically tuned? Ideally this would be done by simply moving things into different folders in IMAP (e.g. move something into the Spam folder, it gets flagged as spam. Move something out of the spam folder, it gets flagged as not-spam.) rather than needing a separate web interface. If so, how did you go about setting that up?
I ask because I've been looking at doing something similar, but haven't found anything that does quite what I want.
True about the desktop version. They had something that claimed to be a desktop version, but when I ran it the first thing it wanted was a mobile #. Uhh.... my desktop PC doesn't have a phone number!
Signal uses your mobile number as a unique identifier akin to a username. Even if you don't run the app on a phone, you need to give it a mobile number to actually use the service.
That said, Signal is designed to be mainly used on mobile devices. The desktop version is convenient, but isn't really meant to be the primary means of using the service.
It's easy to know how a GPS receiver will work if there's no signal: it simply doesn't function.
But how does it function in the presence of strong jamming signals of different types? Does it produce spurious errors? False position or timing data? Does it have other issues? Can very strong signals cause damage to various components like amplifiers and the exquisitely sensitive receiver circuits?
I'm just speculating, but I suspect that they'll be doing tests of that type.
Have good, versioned backups. I like CrashPlan, as one can use it to backup to various destinations, including local systems/disks, remote systems associated with one's account, remote systems belonging to others (so long as they give permission), and for paid users, to the CrashPlan-run storage service.
All backups are encrypted so that the destinations cannot access one's data, it keeps regular versions so one can easily recover from a ransomware (or other) infection that corrupts or destroys files slowly over time, and compresses/deduplicates data to save space. I've used it for years and it's saved my bacon a few times. Their family plans are quite affordable.
(Disclosure: I am a paid CrashPlan user but otherwise have no connection, financial or otherwise, with the service.)
I'm under no obligation to pay until the investigation and any related processes are ongoing.
Sorry, it's late. I meant to say I'm under no obligation to pay until the investigation and any related processes are complete (and I'd only need to pay if the investigation shows the charge was legitimate; obviously I'd not need to pay if the charge was fraudulent).
That's why I essentially never use debit cards and advocate the use of credit cards: if I contest a charge on a debit card, I'm contesting whether or not I should get my own money back and, as you say, the money may be unavailable during the investigation.
With credit cards, I'm contesting if I owe the bank money and I'm under no obligation to pay until the investigation and any related processes are ongoing.
In regards to eBay, the merchants never get your credit card information. Virtually all transactions go through PayPal, which has its own buyer protection options above and beyond what your credit card offers. Things might have been different eight years ago.
You need to convince the bank that any transactions between its being compromised or stolen and your notifying them were not in fact yours. Good luck with that. I would not notice a fraudulent charge until the next monthly statement
I'm not sure where you live, but in the US it's quite easy: most banks allow you to simply mark one or more particular charges as fraudulent using their online banking website. Otherwise, you can report the card as lost/stolen using the website or by calling them. One time, ten years ago, they sent me a form I had to sign and mail back (at their expense) to attest that the charge was fraudulent. Took me about 30 seconds. The one other time I've reported it since then, it was all online with no paperwork. The one time the bank caught it before I did, no paperwork was necessary: they called me, described the suspicious transaction, I confirmed it was fraudulent, and they handled it from there.
There's never been any adversarial questioning or anything from the bank, it's simply routine.
But you sound as if your cards are often compromised, lost or stolen, so it's all the more suprising if your bank cancels the fraudulant charges at the drop of a hat. You must have such a reputation with them that I wonder why they don't cancel your contract instead.
It's happened to me three times in 15 years, never through any fault of my own. I'd hardly consider that "often" or somehow deserving of a "reputation". Even if it was somehow considered excessive, I find it hard to believe that a bank would drop a long-time client simply because they were frequently the victim of crime.
In each case, it's been quite obvious that the charges were unusual and fraudulent: As an example, when my card was compromised one time I lived in Arizona and I regularly made various routine charges (e.g. groceries, gas, food, etc.). It didn't really make sense that my card was used to buy $300 worth of gasoline at a gas station in Florida 20 minutes after I bought my regular groceries in Arizona, so the bank flagged the transaction and called me. Another time it was used to buy household appliances in some distant state I'd never visited to be delivered to an address I had no connection with whatsoever.
Either way, dealing with the aftermath of the fraudulent credit card usage was only the most minor inconvenience. I don't understand why people get so worked up about such things: I'd be more concerned with my name, address, and other account details getting leaked since those can't be changed as easily (if at all).
I've never understood why anyone worries about their credit card information when shopping online: it's literally the least-valuable information that I possess, insofar as its compromise will affect me.
I'm not liable for any fraudulent charges made with my card, and reporting mis-use is the work of a few moments (unless the bank notices it first and notifies me, in which case its even less work for me). A replacement card will be in my mailbox in a few days.
Is it a minor hassle to update the card number on file with various merchants I do business with? Certainly, and I'd rather such a situation if possible, but it's a minor inconvenience in the grand scheme of things.
Other information -- social security numbers, for example -- are much more valuable to criminals (which is dumb: there really should be some better way of identifying someone), and it's a good thing such information is only rarely needed and asked for. In general, SSNs can't be changed and it's a huge pain to recover from identity theft, but a stolen credit card? That's a minor inconvenience, at worst.
The computer you bought 3-5 years ago, barring mechanical failure still meets or exceeds your needs for the most part, so why waste the money?
Indeed. I have a computer that's about 8 years old (Gigabyte-brand motherboard, Intel Core2Quad Q6600, 8GB DDR2 RAM) that I've made only some minor changes to (lots of storage, SSD boot disk, GeForce 550 Ti graphics card, etc.) that's still ticking away just fine. Turns out the Gigabyte's marketing their boards as "ultra-reliable" was accurate.
I intend to upgrade later this year to something a bit more modern (i7, more RAM, new graphics card, bigger monitor, etc.), but the need really hasn't been pressing. Since most games are released for PC and console, developers (annoyingly) target the performance level of the consoles, so the PC has no problems running them even at high graphics settings.
Either way, I won't be using Windows 10 -- I'll image the Windows 7 installation I currently have and move that over to the new system. Worst-case, I re-install Windows 7. When Win7 goes EOL I'll probably switch to Linux.
Why not get the best of both worlds and have automated backups and an encrypted phone?
If you're not comfortable with Google's various backup options (e.g. Google Photos' cloud backup), that's fine: there's alternatives. I use BitTorrent Sync to sync the camera folders on my and my wife's smartphones with our various computers and NAS. Not only does this make it easier to share photos and video with family (I find it easier to share from a computer, rather than from a phone), but it runs continuously so there's only a few seconds between when the photo was taken and when it's available on the computers. Works incredibly well.
You can choose whether or not to sync using your cellular data or just on wifi, depending on your needs.
- Encryption which, as you point out, keeps other parties from knowing the content of data you access. Sure, the bulk of that data may be mundane, everyday stuff that you don't really care if anyone knows about, but there's no harm in keeping it private in transit. It's the same reason you enclose letters in envelopes rather than sending postcards.
- Verifying the authenticity of the server. Domain-validated certificates offer a relatively low level of validation, but they still provide you reasonable assurance that the server you're communicating is the one operated by the actual owner of that domain name -- your connection isn't being intercepted and spoofed by some shady wifi hotspot, for example. Organization-validated and Extended Validation certificates provide higher degrees of validation, and include details (e.g. company name, location, etc.) of the entity to whom the certificate was issued.
- Tamper-resistance. All HTTPS connections provide tamper-resistance by using either HMAC or AEAD ciphersuites. This prevents third parties from altering the content. A public hotspot or your ISP may inject content, malicious or not, into unencrypted connections. HTTPS prevents this.
Considering that there's essentially no costs for using HTTPS (certificates are free or exceedingly cheap, CPUs have hardware support for AES so there's basically no overhead for encrypting data, ECDHE key exchanges are extremely fast, as are ECDSA signatures, and so present minimal load to servers. RSA signing is a bit slower for servers, but modern CPUs are fast and TLS handshakes are brief and only happen occasionally.) and many benefits, why wouldn't everyone want to secure data in transit?
Certificate cost is no longer the obstacle it used to be, as a TLS certificate is free unless you need organizational validation. StartSSL and WoSign have been providing domain-validated (DV) certificates without charge to individuals for years, and automated ACME CA Let's Encrypt has been in operation for several months.
Indeed. TLS certs are, as you point out, available for free. Even if one wishes to pay for a cert, DV certs are available for a pittance: Comodo's PositiveSSL certs are available for as low as $14.97 for three years ($4.99/year) from SSLs.com, a reseller owned by NameCheap. I spend more getting take-out lunch one day than it'd cost to get a cert for three years. That's basically a non-issue when it comes to even the most budget-constrained websites.
Other interesting details: - Comodo's PositiveSSL offering is one of the very few CAs that will not only sign elliptic curve certs, but will do so using a separate, all-ECC certificate chain. Their ECC root is in all major browsers, but it's cross-signed by their UserTrust RSA root for legacy users. Naturally, PositiveSSL also offers an all-RSA chain for those who prefer RSA certificates, but I thought it was cool they offer an all-ECC chain and charge the same price for ECC or RSA certs. - StartSSL recently started signing ECC certs from their RSA chain (4096-bit root, 2048-bit intermediate). While not as quite secure as an all-ECC chain, it's fast: clients can verify the RSA signatures quickly, and the server can perform fast ECDSA signatures/ECDHE key exchanges quickly. - WoSign uses StartPKI, StartSSL's managed-PKI offering that chains up to the StartSSL root. Nifty. I knew StartSSL has offered that for a while but I'd never seen any such intermediates in the wild before.
Full disclosure: I have no relationship with Comodo, StartSSL, SSLs.com, NameCheap, etc. other than being a paying user. I don't get any compensation, direct or otherwise, from mentioning them.
Slashdot Mirror
The security aspect (in regards to revocation) of shorter keys is nice, but encouraging automation to make widespread HTTPS use easy is the whole point of Let's Encrypt. It shouldn't be a surprise that they set cert lifetimes to encourage automation.
Without automation, deploying secure sites is a pain: administrators have to go through tedious, error-prone manual work that the typical mom & pop business or individual website won't bother with. This maintains the status quo, with not many sites being secure.
With automation, the user who otherwise wouldn't deploy HTTPS simply clicks a button on their web host management interface and Presto!, their site has a cert. (Alternatively, HTTPS could be enabled by default for them, as it is with WordPress.com-hosted sites.) For more technical administrators, a simple command-line tool and a cronjob take care of things in seconds. Easy, and it promotes a more secure web.
There's nothing magical about 90 day certs, and the timing was chosen to be short enough to encourage automation while being long enough to allow for manual renewal if needed. Indeed, they even say, "Once automated renewal tools are widely deployed and working well, we may consider even shorter lifetimes." That's fine with me: it's no skin off my back if they start making certs only valid for a week or two, as a daily cronjob manages everything.
Of course, your mileage may vary and you have your preferences. That's totally fine -- I too use non-LE certs for some internal services where automation isn't really viable -- and nobody's forcing you to use their service. It's a free internet, after all, and there's other CAs to choose from.
I don't know of any one-stop-shop (certificate issuance and backup MX service are pretty orthogonal to each other), but there's plenty of CAs out there that will issue you certificates.
This Comodo reseller sells PositiveSSL certs for ~$5/year with a validity time up to 3 years. That's about as cheap as you can get. They also offer (for the next few weeks, at least) GeoTrust, Symantec, and Thawte certs, but the costs for those are higher and they'll stop selling them in December. Comodo offers free S/MIME certs that validate only your email address, as well as paid ones that validate your email and name (if it matters). The paid ones start at $12/year.
Of course, Let's Encrypt is a good option: the certs are free and you can run any of a multitude of ACME clients (or write your own) to validate your domain, generate the key (which is made by and stays on your system), request the certificate, and install the certificate. A simple cronjob handles renewals without any interaction from you. That makes life really easy. They don't do S/MIME certs, though.
It is so over the top to stop trusting them "for evermore" because of this that it makes me thing they're trying to corner the free SSL cert marker with Let's Encrypt.
To what end? Let's Encrypt has gotten some funding from Mozilla and others, but otherwise is a separate entity run by the ISRG.
Since they don't sell any certificates (they're all free of cost) and running the service ends up costing lots of money (about $3m/year, they say), what motive would they have for "corner[ing] the free SSL cert marke[t]"?
Nothing's preventing anyone else from starting a free CA.
You don't have to run their software (that is, the reference implementation) on your servers. There's plenty of other ACME clients, including short Bash scripts that don't require root and are relatively easy to audit. You could write your own, if you want.
The short expiration times for Let's Encrypt certs exist for two reasons:
1. Revoking certs is a pain. Yes, OCSP is a thing, but malicious actors that can control the network can block OCSP and force users to keep trusting revoked certificates up to their expiration time. Most browsers treat OCSP failures as a soft-fail. This is partially alleviated with OCSP stapling, but not many servers support it. By having short certificate lifetimes, the window of validity for a compromised certificate is smaller.
2. It encourages automation. Rather than certificate issuance (and renewal) being an unusual thing that one needs to do every 1-3 years, during which time one likely has forgotten the procedure and has to go through many manual steps, issuing and renewing certs becomes routine and something easily scriptable and handled by automation. This makes it easier for more sites to deploy HTTPS, and for hosts to enable it with easy, automated tools.
Of course, there's plenty of other CAs out there offering relatively inexpensive certificates with longer lifetimes if you wish. As you say, that's something you prefer. That's fine too: I use LE certs for most of my sites, but some long-lived ones from other CAs for others. It's nice having options.
Which goes to show you how leaking of telemetry info is one of the biggest problems with certs.
How so?
So I have a server on my local network. To enable https, it needs a cert and you click through a form to create a Lets Encrypt cert. BUT if you do that, then you've injected an outside body in the verification!
What do you mean? If you mean the server validates its identity to the certificate authority, then yes, that's true. That's the point.
Each time it contacts that to check the cert, its informing the certificate company that you are accessing your own server on your own network
Let's Encrypt intends that the certificate issuance process is automated, such as with a cronjob. Thus, if you do things right, the server will periodically re-validate your site with Let's Encrypt and renew certificates automatically. This is intended.
If you mean that clients will query the CA's OCSP servers to verify the validity of the certificate, yes, this is true and a minor privacy concern. Fortunately, all modern browsers and servers support OCSP stapling. The server can, with a few lines (or enabling an option in Certbot, the major Let's Encrypt client), handle the OCSP checking itself and "staple" a signed OCSP response to the normal secure handshake. The stapled response is valid for a short period of time (a few days) and the server will query the OCSP servers periodically to get a fresh response. This way, clients don't reveal their browsing habits to the CA and the CA requires less resources for their OCSP servers. Win-win for all. If you haven't already, turn on OCSP stapling on your server.
Of course, if a server doesn't support OCSP stapling, browsers will fall back to querying the CA's OCSP responders.
Firefox should handle self signed certificates better. It treats them as dodgy, but they are not.
How would the browser know they're not dodgy? They are, by definition, self-issued. Anyone, including a bad guy, can make a self-signed certificate saying they're anyone else. There's no in-band way of authenticating a self-signed certificate.
Sure, one can manually elect to trust a self-signed certificate if one knows what one's doing, but the typical user is not knowledgeable enough to do that securely.
A certificate authority injected between you and a known server represents an unwanted man-in-the-middle.
The CA is not a "man in the middle", in that they're not involved in the secure handshake at all. They simply are a third party vouching for the validity of the information contained in the certificate: "We verified that the administrator of www.example.com controls that site and requested a certificate."
CAs undergo stringent vetting and auditing to ensure they follow specific policies before they're trusted by browsers, as well as annual audits thereafter. Is it perfect? No. Have CAs made errors, been compromised, or acted poorly? Yes, and in many cases those CAs received the "death penalty" of having their trust revoked by browsers. Still, it's the least-bad system available that scales for the internet. If you can think of something better, by all means, implement it.
... Letsencrypt provided certificates that lasted longer than 90 days. Ridiculous. Make it one year at least. Please.
The process is intended to be automated, such as with a cronjob, and the short lifetime is intended to resolve issues relating to the general suckitude of revocation.
It's only "free" if you don't value your time (the certs expire every few months), or if you don't need an EV cert, or if you don't need a wildcard cert.
Let's Encrypt intends that the installation and maintenance (e.g. renewal) is automated. A simple daily cronjob checks if any Let's Encrypt certs on that system are in need of renewal and, if so, handles the validation, issuance, and installation of those certs completely automatically. If anything, it dramatically *saves* admin time.
The vast majority of sites don't need EV or wildcard certs, so Let's Encrypt is perfect for them.
It says it needs access to:
Device & App History
[snip]
All the permissions Signal requires are explained here. They all make sense in context, and many can be disabled without affecting normal use (e.g. location, calendar, camera, etc.).
To answer your question about SMS in particular, OWS says "Signal is capable of functioning as a complete replacement to your phone’s stock messaging application. In order to do this, it needs to be able to send and receive text messages (both SMS and MMS). You can also import your existing messages into Signal when it is first installed, and these permissions allow that database to be read as well."
That's all perfectly true, but how do you get the clients to trust the alternate root? Essentially all DNSSEC-capable resolvers come with the ICANN root being trusted. Essentially all the distribution channels are protected from tampering (e.g. package managers like apt, downloading binaries or source from the developer's website, etc. all use digital signatures, many use HTTPS, etc.).
Short of impractically-extreme measures (e.g. maintaining and mandating the use of software repos, mirrors, etc. that include the alternate root's key, mirroring the entire DNS tree with entries signed by the alternate root), even state-level attackers will have a tough time forcing clients to trust the alternate root key.
Gah. I borked the quoting a bit. Apologies.
How exactly then will this work when one DNS server has a record for one Ip address and another points to another such as an anti Putin site?
DNSSEC.
Due to the nature of DNSSEC, so long as the root is trusted all DNSSEC-enabled domains (assuming they're part of a signed TLD) are protected from such forgeries.
A large-scale attacker could certainly setup their own DNS infrastructure that's essentially the same as the standard system but with some minor modifications to redirect specific domain names to systems they control, but this would cause DNSSEC failures (assuming the resolver supports DNSSEC).
For completely free certs? Those are the only ones I know.
Sites like ssls.com sells, among others, Comodo DV certs for like $5/year. Not free, but close enough for most purposes.
Out of curiosity, does your setup provide per-user control over spam/not-spam? That is, can a user flag a false-negative as spam and a false-positive as not-spam so the filters can be automatically tuned? Ideally this would be done by simply moving things into different folders in IMAP (e.g. move something into the Spam folder, it gets flagged as spam. Move something out of the spam folder, it gets flagged as not-spam.) rather than needing a separate web interface. If so, how did you go about setting that up?
I ask because I've been looking at doing something similar, but haven't found anything that does quite what I want.
True about the desktop version. They had something that claimed to be a desktop version, but when I ran it the first thing it wanted was a mobile #. Uhh.... my desktop PC doesn't have a phone number!
Signal uses your mobile number as a unique identifier akin to a username. Even if you don't run the app on a phone, you need to give it a mobile number to actually use the service.
That said, Signal is designed to be mainly used on mobile devices. The desktop version is convenient, but isn't really meant to be the primary means of using the service.
The one your friends and family use. What's the point of a secure messaging network if nobody you know uses it?
Users can install multiple messaging apps. I, for one, have several: Signal, WhatsApp, Google Hangouts, Skype, etc.
So far it works fine, and most of my friends and family use Signal.
It's easy to know how a GPS receiver will work if there's no signal: it simply doesn't function.
But how does it function in the presence of strong jamming signals of different types? Does it produce spurious errors? False position or timing data? Does it have other issues? Can very strong signals cause damage to various components like amplifiers and the exquisitely sensitive receiver circuits?
I'm just speculating, but I suspect that they'll be doing tests of that type.
Have good, versioned backups. I like CrashPlan, as one can use it to backup to various destinations, including local systems/disks, remote systems associated with one's account, remote systems belonging to others (so long as they give permission), and for paid users, to the CrashPlan-run storage service.
All backups are encrypted so that the destinations cannot access one's data, it keeps regular versions so one can easily recover from a ransomware (or other) infection that corrupts or destroys files slowly over time, and compresses/deduplicates data to save space. I've used it for years and it's saved my bacon a few times. Their family plans are quite affordable.
(Disclosure: I am a paid CrashPlan user but otherwise have no connection, financial or otherwise, with the service.)
I'm under no obligation to pay until the investigation and any related processes are ongoing.
Sorry, it's late. I meant to say I'm under no obligation to pay until the investigation and any related processes are complete (and I'd only need to pay if the investigation shows the charge was legitimate; obviously I'd not need to pay if the charge was fraudulent).
That's why I essentially never use debit cards and advocate the use of credit cards: if I contest a charge on a debit card, I'm contesting whether or not I should get my own money back and, as you say, the money may be unavailable during the investigation.
With credit cards, I'm contesting if I owe the bank money and I'm under no obligation to pay until the investigation and any related processes are ongoing.
In regards to eBay, the merchants never get your credit card information. Virtually all transactions go through PayPal, which has its own buyer protection options above and beyond what your credit card offers. Things might have been different eight years ago.
You need to convince the bank that any transactions between its being compromised or stolen and your notifying them were not in fact yours. Good luck with that. I would not notice a fraudulent charge until the next monthly statement
I'm not sure where you live, but in the US it's quite easy: most banks allow you to simply mark one or more particular charges as fraudulent using their online banking website. Otherwise, you can report the card as lost/stolen using the website or by calling them. One time, ten years ago, they sent me a form I had to sign and mail back (at their expense) to attest that the charge was fraudulent. Took me about 30 seconds. The one other time I've reported it since then, it was all online with no paperwork. The one time the bank caught it before I did, no paperwork was necessary: they called me, described the suspicious transaction, I confirmed it was fraudulent, and they handled it from there.
There's never been any adversarial questioning or anything from the bank, it's simply routine.
But you sound as if your cards are often compromised, lost or stolen, so it's all the more suprising if your bank cancels the fraudulant charges at the drop of a hat. You must have such a reputation with them that I wonder why they don't cancel your contract instead.
It's happened to me three times in 15 years, never through any fault of my own. I'd hardly consider that "often" or somehow deserving of a "reputation". Even if it was somehow considered excessive, I find it hard to believe that a bank would drop a long-time client simply because they were frequently the victim of crime.
In each case, it's been quite obvious that the charges were unusual and fraudulent: As an example, when my card was compromised one time I lived in Arizona and I regularly made various routine charges (e.g. groceries, gas, food, etc.). It didn't really make sense that my card was used to buy $300 worth of gasoline at a gas station in Florida 20 minutes after I bought my regular groceries in Arizona, so the bank flagged the transaction and called me. Another time it was used to buy household appliances in some distant state I'd never visited to be delivered to an address I had no connection with whatsoever.
Either way, dealing with the aftermath of the fraudulent credit card usage was only the most minor inconvenience. I don't understand why people get so worked up about such things: I'd be more concerned with my name, address, and other account details getting leaked since those can't be changed as easily (if at all).
I've never understood why anyone worries about their credit card information when shopping online: it's literally the least-valuable information that I possess, insofar as its compromise will affect me.
I'm not liable for any fraudulent charges made with my card, and reporting mis-use is the work of a few moments (unless the bank notices it first and notifies me, in which case its even less work for me). A replacement card will be in my mailbox in a few days.
Is it a minor hassle to update the card number on file with various merchants I do business with? Certainly, and I'd rather such a situation if possible, but it's a minor inconvenience in the grand scheme of things.
Other information -- social security numbers, for example -- are much more valuable to criminals (which is dumb: there really should be some better way of identifying someone), and it's a good thing such information is only rarely needed and asked for. In general, SSNs can't be changed and it's a huge pain to recover from identity theft, but a stolen credit card? That's a minor inconvenience, at worst.
The computer you bought 3-5 years ago, barring mechanical failure still meets or exceeds your needs for the most part, so why waste the money?
Indeed. I have a computer that's about 8 years old (Gigabyte-brand motherboard, Intel Core2Quad Q6600, 8GB DDR2 RAM) that I've made only some minor changes to (lots of storage, SSD boot disk, GeForce 550 Ti graphics card, etc.) that's still ticking away just fine. Turns out the Gigabyte's marketing their boards as "ultra-reliable" was accurate.
I intend to upgrade later this year to something a bit more modern (i7, more RAM, new graphics card, bigger monitor, etc.), but the need really hasn't been pressing. Since most games are released for PC and console, developers (annoyingly) target the performance level of the consoles, so the PC has no problems running them even at high graphics settings.
Either way, I won't be using Windows 10 -- I'll image the Windows 7 installation I currently have and move that over to the new system. Worst-case, I re-install Windows 7. When Win7 goes EOL I'll probably switch to Linux.
Why not get the best of both worlds and have automated backups and an encrypted phone?
If you're not comfortable with Google's various backup options (e.g. Google Photos' cloud backup), that's fine: there's alternatives. I use BitTorrent Sync to sync the camera folders on my and my wife's smartphones with our various computers and NAS. Not only does this make it easier to share photos and video with family (I find it easier to share from a computer, rather than from a phone), but it runs continuously so there's only a few seconds between when the photo was taken and when it's available on the computers. Works incredibly well.
You can choose whether or not to sync using your cellular data or just on wifi, depending on your needs.
HTTPS provides several benefits:
- Encryption which, as you point out, keeps other parties from knowing the content of data you access. Sure, the bulk of that data may be mundane, everyday stuff that you don't really care if anyone knows about, but there's no harm in keeping it private in transit. It's the same reason you enclose letters in envelopes rather than sending postcards.
- Verifying the authenticity of the server. Domain-validated certificates offer a relatively low level of validation, but they still provide you reasonable assurance that the server you're communicating is the one operated by the actual owner of that domain name -- your connection isn't being intercepted and spoofed by some shady wifi hotspot, for example. Organization-validated and Extended Validation certificates provide higher degrees of validation, and include details (e.g. company name, location, etc.) of the entity to whom the certificate was issued.
- Tamper-resistance. All HTTPS connections provide tamper-resistance by using either HMAC or AEAD ciphersuites. This prevents third parties from altering the content. A public hotspot or your ISP may inject content, malicious or not, into unencrypted connections. HTTPS prevents this.
Considering that there's essentially no costs for using HTTPS (certificates are free or exceedingly cheap, CPUs have hardware support for AES so there's basically no overhead for encrypting data, ECDHE key exchanges are extremely fast, as are ECDSA signatures, and so present minimal load to servers. RSA signing is a bit slower for servers, but modern CPUs are fast and TLS handshakes are brief and only happen occasionally.) and many benefits, why wouldn't everyone want to secure data in transit?
Certificate cost is no longer the obstacle it used to be, as a TLS certificate is free unless you need organizational validation. StartSSL and WoSign have been providing domain-validated (DV) certificates without charge to individuals for years, and automated ACME CA Let's Encrypt has been in operation for several months.
Indeed. TLS certs are, as you point out, available for free. Even if one wishes to pay for a cert, DV certs are available for a pittance: Comodo's PositiveSSL certs are available for as low as $14.97 for three years ($4.99/year) from SSLs.com, a reseller owned by NameCheap. I spend more getting take-out lunch one day than it'd cost to get a cert for three years. That's basically a non-issue when it comes to even the most budget-constrained websites.
Other interesting details:
- Comodo's PositiveSSL offering is one of the very few CAs that will not only sign elliptic curve certs, but will do so using a separate, all-ECC certificate chain. Their ECC root is in all major browsers, but it's cross-signed by their UserTrust RSA root for legacy users. Naturally, PositiveSSL also offers an all-RSA chain for those who prefer RSA certificates, but I thought it was cool they offer an all-ECC chain and charge the same price for ECC or RSA certs.
- StartSSL recently started signing ECC certs from their RSA chain (4096-bit root, 2048-bit intermediate). While not as quite secure as an all-ECC chain, it's fast: clients can verify the RSA signatures quickly, and the server can perform fast ECDSA signatures/ECDHE key exchanges quickly.
- WoSign uses StartPKI, StartSSL's managed-PKI offering that chains up to the StartSSL root. Nifty. I knew StartSSL has offered that for a while but I'd never seen any such intermediates in the wild before.
Full disclosure: I have no relationship with Comodo, StartSSL, SSLs.com, NameCheap, etc. other than being a paying user. I don't get any compensation, direct or otherwise, from mentioning them.