THE most dubious phrase in English after "act natural" is "trust me". A party asking for trust without offering a reason why is probably untrustworthy. And yet the internet's entire security ecosystem relies on precisely that reasoning. Browsers believe in the integrity of secured websites based on other unknown parties' word. In these complicated times such implicit trust may be misplaced. Thankfully, work is afoot to change how trust is assigned, and it cannot come too quickly.

A month ago, this Babbage extolled Democratic Senator Charles Schumer's exhortations to major web companies to make secure connections the default method for users. This would keep malicious parties from hijacking sessions with social media and other sites on open networks, especially Wi-Fi hot spots.

Commenters suggested your correspondent was naive, and perhaps rightly so. The encryption used by secure websites relies on tenuous relationships. Critics noted that the system that validates the integrity of a protected connection may already be subverted by nations and individuals. In fact, a breach of security at Comodo, a firm that creates security documents for websites, among its other businesses, revealed just how weak the system is. Allegedly, an Iranian cracker was able to issue himself—through a Comodo affiliate—valid certificates for domains at Skype and other firms.

When a surfer connects to a site that uses something called SSL/TLS, the only worldwide standard used to initiate and encrypt connections, a web server provides information that the surfer's browser is meant to check. The information comes in the form of a certificate, which is counter-signed by third parties known as certificate authorities (CAs). (Private web and other communications use variants of this approach; its strength can be ratcheted up, too.)

CAs are, in turn, signed off on by browser makers and operating-system (OS) designers—some browsers consult an internal list of CAs and others turn to a list embedded in the OS. In either case, the system uses detail provided by the CA to confirm that the certificate is legitimate. But what does legitimate mean, in this context? Well, just that a CA says it is legitimate. In other words, "trust me". Currently, any CA in the world may vouch for the authenticity and integrity of a certificate for any domain name in the world, as it pleases.

Many governmentshave indirect or direct ties to some of the hundreds of CAs approved by Microsoft (OS and Internet Explorer), Apple (OS and Safari), the Mozilla Foundation (Firefox) and Google (Chrome). Democracies like Britain or the United States might formerly have adopted a hands-off policy on such matters. But shell games with certificates can, in principle, be used to intercept nominally secure data. Worse still, such ploys are often undetectable. But not all countries are democracies. And even those can sometimes be a little too prying.

SSL/TLS certificates are scoped to a specific name at a domain, such as www.economist.com. When a secure URL is entered or clicked in a browser, the operating system converts this name into a machine-readable address like, for The Economist, 64.14.173.20, using the decentralised domain-name system (DNS) to handle the query. However, DNS can easily be subverted: a home computer can be infected with a virus which rewrites the queries before they get to the DNS server and diverts them to a malicious site; at the other end of the scale, a sovereign can mislead all the machines connected anywhere in a given country. (This is routine at Wi-Fi hotspots. After you connect to most such networks and try to view a page, your browser is redirected to a "splash" page for logging in or accepting usage terms. The DNS request is intercepted and rewritten by a device on the venue's network.)

The secure web infrastructure was designed in part to defend against this. The browser may be tricked into connecting to a server designed to extract your identity or intercept communications, but the browser will see the wolf under the sheep's clothing. It will alert the user and hinder him from connecting to a server that lacks a certificate, issued by some CA, for the domain it claims to be representing. But if a valid certificate can be obtained, neither the user nor the browser have any idea that they have been hijacked.

These issues are well known to the boffins who run the parts of the internet most users never need to know about. Stephen Schultze, the associate director of Princeton's Center for Information Technology Policy, says that a number of changes in how people apportion trust could alleviate the most severe risks of the present system.

First, browser and OS makers ought to prevent CAs from issuing certificates willy-nilly, but so far have not been serious about it. Apple, Google, Microsoft, and other OS and browser firms may offend governments in countries in which they do business by not accepting all certificates as valid from CAs with sovereign or nepotistic ties, and limiting them to validating specific country domains (such as .cn or .uk). But Mr Schultze says these firms may stiffen their resolve after recent breaches, which affect their own businesses and give the heebie-jeebies to their customers. At the very least, CAs may be subject to stricter vetting (and perhaps auditing) to be included on approved lists.

Second, browsers could offer tools that resemble ad blockers or spam blacklists that would allow non-expert users to avoid connections to illegitimate sites that seem to have been validated. Along these lines, Google announced on April 1st that it had assembled, and would update a global almanac of SSL/TLS certificates. It retrieves security data routinely while indexing the web. These data could be consulted by browsers or third-party plugins to sniff out unusual changes in security documents and warn users—or simply prevent a connection.

Finally, a comprehensive solution would let domain owners confirm that the names and machine numbers issued by a given CA are kosher. Under DNS-based Authentication of Named Entities (DANE), a standard being developed by Mr Schultze and others at the Internet Engineering Task Force, a browser retrieves a certificate from a web server, but checks with the DNS whether the certificate is in fact the one that was issued to a given domain owner. So, though a CA will still provide a validation step, the domain owner will have had to give it the thumbs up first. To prevent malevolent fiddling the DNS infrastructure itself needs to be secured, too. A long-running effort to do this, known as DNSSEC, hit a key milestone in 2010 and may have enough pieces in place soon to be usable. This is important because DANE would be incomplete without it.

Whilst all current browsers must be updated to take advantage of DANE, the new system can coexist with the old, and a gradual transition can be made. Browser plug-ins could bridge the gap before browser makers build in DANE, too. Those that want the added robustness of the new system—whether individuals, companies, or governments—may accelerate the adoption of updated browsers as DANE becomes available.

These moves do not provide total assurance that what your browser is told about an internet site's identity and security is true. Trust, but verify—and verify again.