[popey456963]

Why on Earth could they possibly feel it necessary to do this? The United States Patent Office doesn't have a complex system of sub-domains or even an EV license, if money were the object then they could just go with Let's Encrypt (not to mention the current license continues until 2018 anyway).

The amount of computing power it takes to encrypt with SSL is minimal, especially if you use some of the newer systems like ECDSA and should not be of concern to a company like the Patent Office.

[anigbrowl]

You think they have a free hand, but they don't. People who work are federal agencies are hemmed in by a thicket of rules that prevent them from just entering into an agreement with a private vendor who has not been through a qualification process. Likewise technicians and administrators are enjoined from spending money on their own initiative, eg you can't just see the problem, sign up for a renewable SSL certificate, and then shoot the bill over the accounts payable.

I don't want to speculate about what's going on at the managerial/administrative level, but I notice the current administration is committed to the goal of slashing most government spending by some huge amount while simultaneously cutting taxes. It may be that the head of the USPTO got a phone call telling them not to spend a single damn penny. Now, iirc the USPTO is actually self-financing on patent application fees, but I don't think they're so independent that they can just ignore directives from higher up in the executive branch.

[fapjacks]

Totally this. I have childhood friends who now work in government IT and I just can't wrap my head around how these people get anything done in those kinds of environments.

[k_sh]

sounds like the US government is ripe for disruption...

/s

[a3n]

Maybe they fired or lost the only person left who understood how it works, it broke, and whoever they yanked across the hall to get it going again could only do it this way. I think there's still a govt-wide hiring freeze.

[shimon_e]

Hiring freeze was lifted on April 12, 2017.

[drdaeman]

Maybe someone sued them over some highly-innovative encryption patent they've previously granted? :) /s

[jbob2000]

Well if you put on your tinfoil hat - maybe someone wants to track who's viewing which patents, which they can't do when it's encrypted. You're right, it doesn't make any sense to do this, so there must be an ulterior motive.

[stonesam92]

If that were the case and USPTO were in on the trick, why the need to drop HTTPS?

They'd have that data already, so could just share it directly.

[zkms]

> Well if you put on your tinfoil hat - maybe someone wants to track who's viewing which patents, which they can't do when it's encrypted.

No, a third-party attacker can just look at size/timing of packets to figure out which page is being viewed, especially given it's among a limited and static corpus.

[jagger27]

Tracking users over HTTPS is a solved problem, so I doubt that'd be it. Something about "never attribute to malice that which can be adequately explained by incompetence"?

[cookiecaper]

I would assume that they do it because HTTPS does complicate the pipeline on several different levels. If you want to tcpdump the https traffic, for example, you need to do SSL/TLS termination at the load balancer to get something readable. Most web servers don't make it easy to inject on the other side of the decryption; I remember having to enable some very verbose debug logs in nginx to accommodate this. Third-party tooling is necessary to take a dump of encrypted traffic and decrypt it for analysis.

It's also possible that their configuration was causing them performance problems and decreasing overhead by killing HTTPS for "unnecessary" endpoints was seen as a potential solution. Requesting a public record about a patent is not something that, at first glance, seems like it should need to be transferred over a secure protocol.

Of course, none of these are really good reasons to disable HTTPS, but they're some potential explanations.

-----

Separately, I think some people who remember HTTPS being used to secure "true secret" pages kind of resent the "HTTPS must be used anywhere and everywhere" trend that has taken hold. It's not that there aren't good reasons to do that, but it's also silly to pretend there aren't side effects of doing it.

From some perspectives, the need to encrypt all communication can be seen as an external concern for something like a VPN tunnel to handle. End-to-end crypto is good because it, theoretically, precludes reception from anyone who can get in the middle of the server and the VPN, but it needs to be more transparent before everyone is willing to consider that a worthwhile/important tradeoff.

One side effect of HTTPS everywhere is that the site can no longer really designate some portion of traffic as "secret". If every admin in your org needs to be able to decrypt all HTTPS traffic to debug issues, you're giving some access away. Maybe some of them would've been able to get to that data anyway, but probably many of them would not.

Again, this is not to say that that HTTPS shouldn't be used, but just some musings into why someone would not necessarily be enthusiastic about it. Working to integrate HTTPS more transparently to admins and working toward the ability to mark specific information for extra "app-layer secrecy" instead of just relying on transport-layer secrecy seem like they'd be good steps.

[dsmithatx]

You could easily terminate SSL at the LB or even just a proxy in front of the app. Sniffing the line after that is as trivial as turning a mirror port on the switch. In this day and age SSL is trivial and there is honestly no good reason to disable it. In fact protecting users privacy is a good reason they should switch to SSL only.

I know you were only trying to coming up with some kind of reason but, there just isn't a valid one.