Sarcasm aside, I'm really interested in reading more about that.
Sarcasm aside, I'm really interested in reading more about that.
I have Huawei USB cellular modem that identifies itself simultaneously as:
1. USB mass storage, if one has a microSD card in the internal slot. This is handy for storing files and whatnot on the stick.
2. As a CD-ROM drive with a virtual CD containing the drivers needed for the cellular modem functionality, so the user can install the drivers needed while only possessing the stick itself (e.g. no real CD, no internet download, etc.).
3. As a cellular modem.
PAR2 not a filesystem, but rather a means of generating error-correction codes to detect and repair damage to files.
The actual PAR2 algorithm hasn't changed, though development for PAR3 is ongoing. It's simply that one particular implementation, QuickPar, is obsolete, while MultiPar, a similar program that is completely compatible is more modern.
But for infrequently accessed data, AWS Glacier offers the same durability of S3 for only $0.004/GB or $4/TB/month. There's an infrequent access tier in between those two for $12.50/TB/month.
Volume discounts kick in above 50TB.
Online.net's C14 service is even cheaper, at EUR 0.002/GB/month plus EUR 0.01/GB for "operations" (such as creating an archive from the temporary staging area, manually verifying archives on demand, or recovering an archive), and offers the same 99.999999999% durability as Glacier. No bandwidth costs and no complicated retrieval speed costs like Glacier, and you can use rsync to upload to the staging area. Naturally, they perform behind-the-scenes error checking and repair, but the manually-selected verification process is nice to explicitly verify that things are intact.
They offer an "Enterprise" level with even more durability for increased costs (EUR 0.004/GB/month + EUR 0.025/GB for operations), as well as a new "Intensive" level that costs EUR 0.005/GB/month with no operations fees (it's intended for more frequent accesses to backed-up data).
Online.net is owned by Iliad, who in turn is owned by Free, a major French telecom, so the risk of suddenly going out of business is low.
Disclosure: I'm a happy C14 user, but otherwise have no connection to the company.
QuickPar on Windows is long-obsolete. MultiPar is the more modern variant.
Seriously 0.2 is nothing and if that's thrice the limit, then the limit is ridiculously low.
Love from Germany, where the limit is 0.5.
According to this site, the blood alcohol limit in Germany is 0.05%, not 0.5%. That's a factor of ten difference. The limit in the US, according to the same site, is 0.08%, which is even higher than Germany.
The driver described in this article had a BAC four times the legal limit in Germany.
Because that's how they did it before and they consider it "safer" in the context of not making uneccessary changes this soon to the leap second. In the future they plan to do it 24 hours in advance:
Although we decided it would be safest for Google's infrastructure to handle the 2016 leap second using a 20-hour smear, the same way we handled the leap seconds in 2012 and 2015, this is not the only smear that works well. Many organizations use smeared clocks, and it would be helpful if the smears were the same. After all, the purpose of clocks is to read the same time in different places.
We would like to propose to the community, as the best practice for leap seconds in the future, a 24-hour linear smear from noon to noon UTC. We plan to use this smear starting from leap second #38, which is likely to be in 2018.
By "shorter keys" I mean "shorter certificate validity periods". Sorry for the confusion.
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.
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.
Why won't sharks eat lawyers? Professional courtesy.