TidBITS: Why Take Control Was Labeled “Not Secure” Briefly

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

TidBITS: Why Take Control Was Labeled “Not Secure” Briefly

TidBITS Articles
Why Take Control Was Labeled “Not Secure” Briefly

This article was just published by TidBITS and sent to you at your request.

Why Take Control Was Labeled “Not Secure” Briefly

By Adam C. Engst
http://tidbits.com/article/17121

Anyone who visited the Take Control site using Google Chrome from March 9th through 17th might have seen a dire-sounding warning that “Your connection is not private,” much like the screenshot below. That statement was far more extreme than the actual situation, but without knowing the back story, you might have been scared off from using our site. We wanted to apologize, explain what happened, and how we fixed it.

Certificate Background -- First off, the cryptographic foundation for secure Web connections relies on an ecosystem of which “digital certificates” are a vital part. You can judge your connection secure when you load a Web URL that starts with https, the page loads without errors, and the browser shows a lock icon next to the URL in your browser’s address bar. Secure connections prevent bad guys from eavesdropping on your traffic, so it’s safe to transmit credit card details and other sensitive information.

The entire system is based on trust, backed up by verification. (Interestingly, the saying “Trust, but verify,” is a translation of a Russian proverb used regularly by President Ronald Reagan.) At the top level are major browser makers. Apple, Google, Microsoft, and Mozilla all set stiff requirements that third-party verification organizations must meet to be included in — and thus trusted by — their respective browsers.

These third-party verification organizations are called “certificate authorities,” (CAs) because they provide independent authority that a certificate is valid. A top-level, or root, CA has to meet stringent rules for browser makers to bundle its “root certificate” into their browsers. Only several hundred organizations worldwide meet the bar, and browser makers require audits and continuously evaluate reports of any problems.

Root CAs issue what are effectively countersigned certificates: a company like TidBITS that wants to have a secured Web server creates a request with some text portions and some cryptographic ones, and a CA evaluates whether we are a legitimate party for the domain that we want to secure. If we pass its validation, the CA issues a certificate cryptographically signed by it using its root certificate.

You can also work with delegated, or intermediate CAs. Root CAs create intermediate certificates derived from their root certificates to allow other parties, like DNS and Web hosting companies or firms that sell corporate hardware, to create valid certificates that meet the same standards as the root.

The result is a chain of trust, with a CA’s root certificate at one end, often an intermediate certificate from a reseller in the middle, and an individually issued certificate at the other end. By embedding root certificates, browsers (and operating systems) make it possible for a user to know that the connection to a particular Web site is secure: the CA that sold us our certificate vouches that we are who we say we are, and the top-level CA vouches for the issuing CA. In turn, users trust the browser makers to support only trustworthy root certificates. (The browser provides an “out-of-band” element of trust: we’re not using a potentially insecure Internet connection to check that the CA root certificate is valid, because that trust is already baked into the browser.)

This certificate system is based on public key cryptography, with the public certificates associated with private keys held by each entity in the chain. As a result, certificates go beyond verifying identity to enable a Web browser and server to exchange a session encryption key without risk of interception and thus encrypt all the traffic that passes over the connection.

Historically, the process of getting a certificate for your Web server was both expensive and onerous — you could easily drop $300 to $500 a year in the not-so-distant past. Since 2010, when we first went down this road, we’ve worked with a CA called StartCom, which offered substantially less expensive certificates. Getting a certificate from StartCom required multiple authentication steps and scans of legal documents that confirmed our personal and corporate identities, and the process always ended with a phone call to check the details.

Once I had the certificate from StartCom, I had to install it, which involved copying it and StartCom’s intermediate certificate to our server and modifying Apache and Sendmail configuration files to point to it. The certificate was good for two years, so I’ve had to repeat the process three times so far, and honestly, I hate it. I had to take copious notes so I could recreate the steps, and since I’m merely adequate at Unix administration, I was always worried I’d mess something up badly. Nevertheless, I managed to do it, with the last renewal coming in August 2016. (Our long-running on-demand system admin, Glenn Fleishman, also used StartCom until this fussiness got to him a few years ago.)

StartCom Problems -- Here’s where our problems started. It appears that StartCom was quietly acquired by a Chinese CA called WoSign in late 2015. The specifics are still murky, but between the details of the acquisition not being made public and various bad actions on the part of WoSign, Apple, Google, and Mozilla all announced last fall that their Web browsers would no longer trust new certificates issued by StartCom.

That didn’t affect us until 9 March 2017 when Google released Chrome version 57, which also stopped trusting StartCom’s old certificates — including ours. Suddenly, Chrome 57 users saw that “Your connection is not private” interstitial warning before our site loaded. If someone went past that by clicking the Advanced link and the Proceed link, all pages on the Take Control site were labeled as “Not Secure.” You can imagine my consternation! Neither Safari nor Firefox complained because they still trust StartCom’s old certificates. Luckily, because Chrome updates itself over time, and needs to be relaunched before the new version loads, relatively few people saw the problem.

(Thanks to Twitter user @shepgo for alerting me to Chrome’s behavior, since even though he and I weren’t able to figure out what was happening then due to the fact that my copy of Chrome hadn’t updated itself to version 57 yet, when we got a customer complaint the next day, I was able to put it all together fairly quickly.)

Despite these warnings, nothing had actually changed with the security on our site or with the encryption for traffic to and from our site. (I verified this with TidBITS security editor Rich Mogull.) However, Google no longer wanted to use its reputation to vouch for a user’s privacy, because it had stopped trusting StartCom to behave reputably. A more accurate version of the message could have said, “Google cannot verify your connection is private,” but that doesn’t light a fire under users. In essence, Google, along with Apple and Mozilla, were punishing StartCom and WoSign for bad behavior by ensuring an exodus of their customers. It worked.

(StartCom could have dealt with this problem in a positive and proactive way by alerting all its certificate holders about the problem and suggesting a move to other valid CAs until it could reorganize itself and regain trust. It did nothing along these lines, which is why this situation became a crisis rather than a technical task I could have handled in a more relaxed fashion.)

Hey Folks, Let’s Encrypt! -- Once we figured out what had happened, we switched to using Let’s Encrypt, a non-profit CA that provides free certificates. Let’s Encrypt’s certificates are good only for 90 days and must be renewed after that time, although that can (and should) be automated easily.

Happily, Let’s Encrypt has radically simplified the process that I had so laboriously sweated through with StartCom every two years, thanks to client software that supports ACME (Automatic Certificate Management Environment). There are numerous ACME clients that you can run on your Web server, but Let’s Encrypt recommends the EFF’s Certbot, which is relatively easy to install and run on a wide variety of operating systems and with different Web servers. Instead of making you jump through identification hoops, Certbot validates that your Web server is authoritative for your domain by making sure it can confirm a connection to the server using the domain names you claim that you control. This is apparently sufficient for the chain of trust.

If you’re familiar with installing Unix apps, you’ll have no trouble with Certbot. I got Glenn to help since I always worry that I’ll do something that will kill the server. In the end, however, it turned out to be almost shockingly simple. We used wget to grab a copy of Certbot, changed some permissions, and when we ran it, it installed itself. Actually getting and installing a certificate just involved running Certbot again with a flag that told it to configure everything for Apache. It read our configuration files, asked a few questions about what domains to support, acquired and installed a certificate, and updated our Apache .conf files.

Although I didn’t set up Certbot to renew our certificate automatically because I want to see it work the first time, I’ll do that after the first manual renewal by creating a cron job that schedules Certbot to renew the certificate on its own. (Certbot provides a “dry run” option for automatic renewal that lets you test whether any problems would crop up.)

Throughout all this, I was running the Qualys SSL Server Test, and even after switching to Let’s Encrypt, we were getting only a B rating. Some more research revealed that our Apache .conf files weren’t setting choices of SSL ciphers optimally, so the server could potentially use some ciphers that weren’t as secure as others. When I fixed the SSL cipher lines according to these recommendations, our site started getting an unqualified A rating. I also had to delete some extraneous lines in the .conf files that still referred to the StartCom certificate.

The main thing I haven’t yet done is replace the StartCom certificate in our Sendmail configuration with the Let’s Encrypt certificate. I believe I know how to do that, but I need to do more research into how Sendmail will realize that Certbot has renewed the certificate.

Though I spent hours figuring out what happened and how to resolve the problem, it was doubly worthwhile in the end, since working with Let’s Encrypt is cheaper and easier than with StartCom, and the additional configuration changes I made further hardened our site’s security.

So, if you’re at all unhappy with your certificate provider, and especially if you bought your certificates from StartCom, I recommend that you give Let’s Encrypt a try.

Post a comment

TidBITS members can unsubscribe from just-published articles at http://tidbits.com/subscriptions. TidBITS Talk readers will need to create a filter to delete these articles.

Article copyright © 2017 By Adam C. Engst . Reuse governed by Creative Commons License.




____________TidBITS Talk Participation Guidelines____________
Post only when you have something substantive to contribute.
Be polite and constructive, and comment on posts, not people.
Quote sparingly, if at all. We all read the previous message.
Start threads with a new message to [hidden email].
Read archives at: http://tidbits.com/pipermail/tidbits-talk/
Unsubscribe at: http://tidbits.com/mailman/options/tidbits-talk
____Mailing List Manners: http://tidbits.com/series/1141 ____
Reply | Threaded
Open this post in threaded view
|

Re: TidBITS: Why Take Control Was Labeled “Not Secure” Briefly

adamengst
Administrator

On Thu, Mar 23, 2017 at 10:18 PM, gastropod <[hidden email]> wrote:
This situation is about to become really common--chrome is just about to
flag all of Symantec's extended certificates as not extended, then
branch out in several stages to flag everything they or their
subsidiaries have issued as insecure.

I added mention of this to the article — I was originally thinking about doing it, but changed my mind at the last minute last night since I was too tired to decide it was related (it is). 

cheers... -Adam



____________TidBITS Talk Participation Guidelines____________
Post only when you have something substantive to contribute.
Be polite and constructive, and comment on posts, not people.
Quote sparingly, if at all. We all read the previous message.
Start threads with a new message to [hidden email].
Read archives at: http://tidbits.com/pipermail/tidbits-talk/
Unsubscribe at: http://tidbits.com/mailman/options/tidbits-talk
____Mailing List Manners: http://tidbits.com/series/1141 ____
Reply | Threaded
Open this post in threaded view
|

Re: TidBITS: Why Take Control Was Labeled “Not Secure” Briefly

Curtis Wilcox
In reply to this post by TidBITS Articles
On Mar 23, 2017, at 8:07 PM, TidBITS Articles <[hidden email]> wrote:

Throughout all this, I was running the Qualys SSL Server Test, and even after switching to Let’s Encrypt, we were getting only a B rating. Some more research revealed that our Apache .conf files weren’t setting choices of SSL ciphers optimally, so the server could potentially use some ciphers that weren’t as secure as others. When I fixed the SSL cipher lines according to these recommendations, our site started getting an unqualified A rating. I also had to delete some extraneous lines in the .conf files that still referred to the StartCom certificate.

A helpful tool for configuring web servers with encryption is the Mozilla SSL Configuration Generator.
Their "Modern" setting for browser compatibility says the browsers compatible with it are a little newer than the ones Hynek lists in his article. Specifically, Hynek says setting SSLProtocol to use only TLS 1.2 is a okay for Safari 7 or newer but Mozilla's modern setting only works with Safari 9 or newer. I think Hynek is being more accurate because I've confirmed Safari 7 supported TLS 1.2 (and Mobile Safari supported it on iOS 5). Mozilla may be assuming that since 7 required Mavericks (10.9) and Mavericks could also run Safari 9, everyone who could run 7 is instead running 9. I don't think there's a meaningful difference between supported cypher suites in 7 and 9.

I mention this because my hunch is TidBITS has some customers who are using older OS X or iOS versions. I think what happens when the browser is too old to negotiate a secure connection to the server is they can't connect at all. Accepting connections from older browsers (i.e. using Mozilla's "Intermediate" setting) might be worth not having an "A" score on SSLabs and not having features like forward secrecy.

The main thing I haven’t yet done is replace the StartCom certificate in our Sendmail configuration with the Let’s Encrypt certificate. I believe I know how to do that, but I need to do more research into how Sendmail will realize that Certbot has renewed the certificate.


Since Let's Encrypt certificates are free, you might consider using different certificates for different services. I've only configured a certificate with Apache, I don't know what it takes to do it with non-web servers.




____________TidBITS Talk Participation Guidelines____________
Post only when you have something substantive to contribute.
Be polite and constructive, and comment on posts, not people.
Quote sparingly, if at all. We all read the previous message.
Start threads with a new message to [hidden email].
Read archives at: http://tidbits.com/pipermail/tidbits-talk/
Unsubscribe at: http://tidbits.com/mailman/options/tidbits-talk
____Mailing List Manners: http://tidbits.com/series/1141 ____
Reply | Threaded
Open this post in threaded view
|

Re: TidBITS: Why Take Control Was Labeled “Not Secure” Briefly

adamengst
Administrator

On Fri, Mar 24, 2017 at 3:51 PM, Curtis Wilcox <[hidden email]> wrote:

A helpful tool for configuring web servers with encryption is the Mozilla SSL Configuration Generator.
Their "Modern" setting for browser compatibility says the browsers compatible with it are a little newer than the ones Hynek lists in his article. Specifically, Hynek says setting SSLProtocol to use only TLS 1.2 is a okay for Safari 7 or newer but Mozilla's modern setting only works with Safari 9 or newer. I think Hynek is being more accurate because I've confirmed Safari 7 supported TLS 1.2 (and Mobile Safari supported it on iOS 5). Mozilla may be assuming that since 7 required Mavericks (10.9) and Mavericks could also run Safari 9, everyone who could run 7 is instead running 9. I don't think there's a meaningful difference between supported cypher suites in 7 and 9.

Interesting! That does look like a useful tool.
 
I mention this because my hunch is TidBITS has some customers who are using older OS X or iOS versions. I think what happens when the browser is too old to negotiate a secure connection to the server is they can't connect at all. Accepting connections from older browsers (i.e. using Mozilla's "Intermediate" setting) might be worth not having an "A" score on SSLabs and not having features like forward secrecy.

I’m not sure what happens either, but no one has complained yet. 

The main thing I haven’t yet done is replace the StartCom certificate in our Sendmail configuration with the Let’s Encrypt certificate. I believe I know how to do that, but I need to do more research into how Sendmail will realize that Certbot has renewed the certificate.

Since Let's Encrypt certificates are free, you might consider using different certificates for different services. I've only configured a certificate with Apache, I don't know what it takes to do it with non-web servers.

At the moment, I’m mostly dreading diving back into the DKIM stuff associated with sendmail. 

cheers... -Adam



____________TidBITS Talk Participation Guidelines____________
Post only when you have something substantive to contribute.
Be polite and constructive, and comment on posts, not people.
Quote sparingly, if at all. We all read the previous message.
Start threads with a new message to [hidden email].
Read archives at: http://tidbits.com/pipermail/tidbits-talk/
Unsubscribe at: http://tidbits.com/mailman/options/tidbits-talk
____Mailing List Manners: http://tidbits.com/series/1141 ____
Reply | Threaded
Open this post in threaded view
|

Re: TidBITS: Why Take Control Was Labeled “Not Secure” Briefly

Rodney

> On Mar 24, 2017, at 22:00, Adam Engst <[hidden email]> wrote:
>
> At the moment, I’m mostly dreading diving back into the DKIM stuff associated with sendmail.

I always thought that it was very appropriate for the O'Reilly Sendmail book to have a bat on the cover.



____________TidBITS Talk Participation Guidelines____________
Post only when you have something substantive to contribute.
Be polite and constructive, and comment on posts, not people.
Quote sparingly, if at all. We all read the previous message.
Start threads with a new message to [hidden email].
Read archives at: http://tidbits.com/pipermail/tidbits-talk/
Unsubscribe at: http://tidbits.com/mailman/options/tidbits-talk
____Mailing List Manners: http://tidbits.com/series/1141 ____
Reply | Threaded
Open this post in threaded view
|

Re: TidBITS: Why Take Control Was Labeled “Not Secure” Briefly

adamengst
Administrator

On Fri, Mar 24, 2017 at 6:16 PM, Rodney <[hidden email]> wrote:
I always thought that it was very appropriate for the O'Reilly Sendmail book to have a bat on the cover.

It should be a Tasmanian devil. :-)

cheers... -Adam 




____________TidBITS Talk Participation Guidelines____________
Post only when you have something substantive to contribute.
Be polite and constructive, and comment on posts, not people.
Quote sparingly, if at all. We all read the previous message.
Start threads with a new message to [hidden email].
Read archives at: http://tidbits.com/pipermail/tidbits-talk/
Unsubscribe at: http://tidbits.com/mailman/options/tidbits-talk
____Mailing List Manners: http://tidbits.com/series/1141 ____
Reply | Threaded
Open this post in threaded view
|

Re: TidBITS: Why Take Control Was Labeled “Not Secure” Briefly

Matthew Barr
This is why I prefer postfix.  

Matthew

(sent from my mobile)

On Mar 24, 2017, at 6:47 PM, Adam Engst <[hidden email]> wrote:


On Fri, Mar 24, 2017 at 6:16 PM, Rodney <[hidden email]> wrote:
I always thought that it was very appropriate for the O'Reilly Sendmail book to have a bat on the cover.

It should be a Tasmanian devil. :-)

cheers... -Adam 



____________TidBITS Talk Participation Guidelines____________
Post only when you have something substantive to contribute.
Be polite and constructive, and comment on posts, not people.
Quote sparingly, if at all. We all read the previous message.
Start threads with a new message to [hidden email].
Read archives at: http://tidbits.com/pipermail/tidbits-talk/
Unsubscribe at: http://tidbits.com/mailman/options/tidbits-talk
____Mailing List Manners: http://tidbits.com/series/1141 ____



____________TidBITS Talk Participation Guidelines____________
Post only when you have something substantive to contribute.
Be polite and constructive, and comment on posts, not people.
Quote sparingly, if at all. We all read the previous message.
Start threads with a new message to [hidden email].
Read archives at: http://tidbits.com/pipermail/tidbits-talk/
Unsubscribe at: http://tidbits.com/mailman/options/tidbits-talk
____Mailing List Manners: http://tidbits.com/series/1141 ____
Reply | Threaded
Open this post in threaded view
|

Re: TidBITS: Why Take Control Was Labeled “Not Secure” Briefly

Roger Henriques
In reply to this post by adamengst
Just saw this in a blog post from the Wordfence folks (they specialise in securing WordPress sites, and I use them on several client sites that I administer):

"Until relatively recently, CAs would generally not issue an SSL certificate to a site that is obviously trying to pretend it is apple.com or microsoft.com. However, there is a new CA called LetsEncrypt which issues free certificates to websites who want to use SSL.

LetsEncrypt has a noble goal. They are trying to make it free to use SSL to encrypt connections on the Web. However, they do not check to see if the website owner is pretending to be someone else. So the effect of this is that we are seeing many phishing sites that have a valid certificate issued by LetsEncrypt and which appear as ‘Secure’ in the Chrome browser."

The full post is at:
https://www.wordfence.com/blog/2017/03/chrome-secure/?utm_source=list&utm_medium=email&utm_campaign=032817

They also point out that even if the certificate is revoked, Chrome will still show the site as being secure (unless the viewer digs into Chrome’s developer tools to check), at least until the site itself is flagged by Google’s list of malicious sites - which may take ’some time'.

Hopefully Lets Encrypt will address this issue with Google…

Roger H.
[hidden email]

> On 24-03-2017, at 5:00 PM, Adam Engst <[hidden email]> wrote:
>
> Since Let's Encrypt certificates are free, you might consider using different certificates for different services. I've only configured a certificate with Apache, I don't know what it takes to do it with non-web servers.




____________TidBITS Talk Participation Guidelines____________
Post only when you have something substantive to contribute.
Be polite and constructive, and comment on posts, not people.
Quote sparingly, if at all. We all read the previous message.
Start threads with a new message to [hidden email].
Read archives at: http://tidbits.com/pipermail/tidbits-talk/
Unsubscribe at: http://tidbits.com/mailman/options/tidbits-talk
____Mailing List Manners: http://tidbits.com/series/1141 ____
Reply | Threaded
Open this post in threaded view
|

Re: TidBITS: Why Take Control Was Labeled “Not Secure” Briefly

adamengst
Administrator

On Tue, Mar 28, 2017 at 12:22 PM, Roger Henriques <[hidden email]> wrote:
LetsEncrypt has a noble goal. They are trying to make it free to use SSL to encrypt connections on the Web. However, they do not check to see if the website owner is pretending to be someone else. So the effect of this is that we are seeing many phishing sites that have a valid certificate issued by LetsEncrypt and which appear as ‘Secure’ in the Chrome browser."

That’s an interesting point. In the article, I said something about how Let’s Encrypt determines that you’re legitimate by ensuring that the server running Certbot is authorized to serve the domain for the certificate, and that is true with these phishing domains as far as I can tell.

Certificates seemingly enable two things: verification of identity and encryption. In a situation like this, the encryption would still be in place between you and the server in question; no one could listen in, perhaps unless the site in question was giving its certificate to other bad guys as well.

The problem comes with the verified identity — the site is exactly what it says it is, but it’s simultaneously trying to look like Google Play or some other legitimate site.

It’s not entirely clear to me that a standard certificate (as opposed to an extended validation certificate) could ever prevent that. With StartCom, for instance, I was able to create a wildcard certificate that worked with all possible subdomains of tidbits.com and takecontrolbooks.com. (Let’s Encrypt doesn’t do wildcard certs.) With a wildcard cert installed, however, you could easily set up a Google Play-lookalike subdomain and have that be “secure.”

It may simply be that phishing sites aren’t one of the things that certificates are useful for combatting.

cheers... -Adam



____________TidBITS Talk Participation Guidelines____________
Post only when you have something substantive to contribute.
Be polite and constructive, and comment on posts, not people.
Quote sparingly, if at all. We all read the previous message.
Start threads with a new message to [hidden email].
Read archives at: http://tidbits.com/pipermail/tidbits-talk/
Unsubscribe at: http://tidbits.com/mailman/options/tidbits-talk
____Mailing List Manners: http://tidbits.com/series/1141 ____
Reply | Threaded
Open this post in threaded view
|

Re: TidBITS: Why Take Control Was Labeled “Not Secure” Briefly

Roger Henriques
On 28-03-2017, at 3:15 PM, Adam Engst <[hidden email]> wrote:
>
> It may simply be that phishing sites aren’t one of the things that certificates are useful for combatting.

Or even that the basic architecture of the WWW cannot be made truly secure without a complete re-write - a rather depressing thought.

Roger H.
[hidden email]




____________TidBITS Talk Participation Guidelines____________
Post only when you have something substantive to contribute.
Be polite and constructive, and comment on posts, not people.
Quote sparingly, if at all. We all read the previous message.
Start threads with a new message to [hidden email].
Read archives at: http://tidbits.com/pipermail/tidbits-talk/
Unsubscribe at: http://tidbits.com/mailman/options/tidbits-talk
____Mailing List Manners: http://tidbits.com/series/1141 ____
Reply | Threaded
Open this post in threaded view
|

Re: TidBITS: Why Take Control Was Labeled “Not Secure” Briefly

Curtis Wilcox
On Mar 28, 2017, at 3:25 PM, Roger Henriques <[hidden email]> wrote:
>
> On 28-03-2017, at 3:15 PM, Adam Engst <[hidden email]> wrote:
>>
>> It may simply be that phishing sites aren’t one of the things that certificates are useful for combatting.
>
> Or even that the basic architecture of the WWW cannot be made truly secure without a complete re-write - a rather depressing thought.

For this specific issue, if every site went to the trouble and expense of getting an Extended Validation Certificate, you could feel a lot more assured about the site you're connecting to being the one you expect but only to a point. TidBITS could get an EV cert so you'd see "TidBITS Publishing Inc." in green in the address bar but if there was another business named "TidBITS Inc." would you even notice the difference visiting their site?

Regular certificates haven't really attested to the identity of a site owner in a long time, Let's Encrypt didn't change that and the Wordfence article says as much. The browsers accept that by burying the identity information of a certificate and just show you a lock icon. The certificate just assures you that you're connecting to the domain name that you see in the browser and that communications between the browser and site are encrypted.

There's no way every person, business, and organization in the world is each going to have a unique identifier that humans can easily differentiate. There are more technical things that can be done to help combat fraudulent domains but the Wordfence article contains the best solution, "The best way to protect yourself against malicious sites, in this case, is to check your web browser’s location bar and read the full website hostname that appears there." Phishing attempts are obvious when you look at the whole hostname (greater prevalence of Unicode domain names may make it harder in the future).




____________TidBITS Talk Participation Guidelines____________
Post only when you have something substantive to contribute.
Be polite and constructive, and comment on posts, not people.
Quote sparingly, if at all. We all read the previous message.
Start threads with a new message to [hidden email].
Read archives at: http://tidbits.com/pipermail/tidbits-talk/
Unsubscribe at: http://tidbits.com/mailman/options/tidbits-talk
____Mailing List Manners: http://tidbits.com/series/1141 ____
Reply | Threaded
Open this post in threaded view
|

Re: TidBITS: Why Take Control Was Labeled “Not Secure” Briefly

@lbutlr
In reply to this post by Roger Henriques
On 2017-03-28 (13:25 MDT), Roger Henriques <[hidden email]> wrote:
>
> On 28-03-2017, at 3:15 PM, Adam Engst <[hidden email]> wrote:
>>
>> It may simply be that phishing sites aren’t one of the things that certificates are useful for combatting.
>
> Or even that the basic architecture of the WWW cannot be made truly secure without a complete re-write - a rather depressing thought.

WWW can be fixed, but it will require moving away from the current certificate authority model.

One issue is that people complete security with identity. Good security does not require identity, but identity does require security.

--
Apple broke AppleScripting signatures in Mail.app, so no random signatures.





____________TidBITS Talk Participation Guidelines____________
Post only when you have something substantive to contribute.
Be polite and constructive, and comment on posts, not people.
Quote sparingly, if at all. We all read the previous message.
Start threads with a new message to [hidden email].
Read archives at: http://tidbits.com/pipermail/tidbits-talk/
Unsubscribe at: http://tidbits.com/mailman/options/tidbits-talk
____Mailing List Manners: http://tidbits.com/series/1141 ____
Reply | Threaded
Open this post in threaded view
|

Re: TidBITS: Why Take Control Was Labeled “Not Secure” Briefly

Ron Risley
In reply to this post by Curtis Wilcox
On Mar 28, 2017, at 13:52, Curtis Wilcox <[hidden email]> wrote:
>
> the Wordfence article contains the best solution, "The best way to protect yourself against malicious sites, in this case, is to check your web browser’s location bar and read the full website hostname that appears there." Phishing attempts are obvious when you look at the whole hostname (greater prevalence of Unicode domain names may make it harder in the future).

Which is yet another reason to use a good password manager; they're not fooled by unicode or other tricks phishers use to create misleading domains.


____________TidBITS Talk Participation Guidelines____________
Post only when you have something substantive to contribute.
Be polite and constructive, and comment on posts, not people.
Quote sparingly, if at all. We all read the previous message.
Start threads with a new message to [hidden email].
Read archives at: http://tidbits.com/pipermail/tidbits-talk/
Unsubscribe at: http://tidbits.com/mailman/options/tidbits-talk
____Mailing List Manners: http://tidbits.com/series/1141 ____