Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×

Comment Re:Falsehoods Developers Believe About Time (Score 4, Informative) 179

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.

Source: https://developers.google.com/time/smear.

Comment Re: Alternatives? (Score 1) 86

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.

Comment Re:Reasonable (free or non-free) Alternatives? (Score 1) 86

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.

Comment Re:Outrageous (Score 1) 86

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.

Comment Re: Alternatives? (Score 2) 86

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.

Comment Re:Leakage of data is a big problem with certs (Score 1) 63

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.

Comment Re: I like the idea of encryption (Score 1, Informative) 63

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.

Comment Re:I thought this app was for privacy? (Score 5, Informative) 88

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."

Comment Re:GAO is right (Score 1) 296

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.

Comment Re:GAO is right (Score 3, Informative) 296

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).

Comment Re:Booo! (Score 1) 29

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.

Slashdot Top Deals

Base 8 is just like base 10, if you are missing two fingers. -- Tom Lehrer

Working...