<nettime> FWD: Please consider the impacts of banning HTTP #107

[nettime's_certificate_authority <nettime@kein.org>]

<https://github.com/WhiteHouse/https/issues/107>

Please consider the impacts of banning HTTP #107

On the website for the HTTPS-Only "Standard", there is a statement that
'there is no such thing as insensitive web traffic' -- yet there is. Due
to many institutions having policies against FTP and peer-to-peer
protocols, HTTP has become the de facto standard in sharing scientific
data.

Much of this traffic is regularly scheduled bulk downloads through wget
and other automated retrieval tools. Forcing these transfers to go to
HTTPS would cause an undue strain on limited resources that have become
even more constrained over the past few years.

Although some data transfers are handled through rsync or scp with the
High Performance extensions to SSH ; this requires coordinating between
each pair of institutions, and requires additional paperwork to track
accounts. This additional paperwork requires collecting Personally
Identifiable Information (PII) that is not necessary when distributing
data over protocols that do not require authentication. This paperwork
has restricted our ability to openly share scientific data with
international partners, and has impacted our sharing with an NSF partner
that had a foreign-born system administrator.

In 2013, the White House Office of Science & Technology Policy issued a
memo on "Increasing Access to the Results of Federally Funded Scientific
Research". This document requires that many agencies must create plans
to make their scientific data available to the public in digital
formats. Even if agencies were to lift their restrictions on
peer-to-peer protocols, they don't scale to track the 100M+ files that
larger projects manage.

The qualities that improve the privacy of HTTPS connections are a
hindrance in bandwidth management. Caching proxies can be used with HTTP
to prevent multiple users from a given site each having to download a
file directly from the source. This is especially important for Near
Real Time (NRT) data in which many sites poll for data, or when remote
websites directly embed image links.

This is also important for times when something makes is announced in
the news. We have had times when we've had to remove 'branding' type
images from our webservers to reduce bandwidth. Even with the crush of
international traffic, we have been able to withstand torrents of
requests that were multiple orders of magnitude higher than our typical
traffic.  It is rare for us to know in advance when our data will be
newsworthy, nor what data specifically will be of interest.

The effect on those without computers at home

This increased bandwidth is not only problematic for those serving the
data, but may also be an issue for those trying to use the data. Schools
and libraries will frequently install proxy servers to both minimize
their bandwidth consuption through caching, but also to prevent students
and patrons from going to inappropriate sites. In some cases, this
filtering is mandated by state or local laws. To comply with these laws,
some institutions block HTTPS entirely.

Larger libraries may have a means to request unrestricted access, but
typically require a separate request each time, to prevent patrons from
looking at materials in eyeshot of children.

As such, requiring HTTPS may make it harder for such institutions to
provide the same level of service while complying with their local laws.
To enable scanning of HTTPS, they could configure their proxies to act
as a man-in-the-middle attack, removing all privacy when the citizens
had otherwise expected it.

Restricting the use of HTTP will require changing a number of scientific
analysis tools.

The overall funding cutbacks of the past few years has led to decreased
funding for maintaining scientific analysis software. A good portion of
it is stable and not under active development.

Many of these packages retrieve data using HTTP. Should that access be
removed, someone will have to adjust the packages to retrieve data using
HTTPS or some other protocol. Additional work may be required in the
future to deal with any future patches to the SSL libraries, whereas
older HTTP protocols can still be supported by modern web servers.

This may be even more of a problem for software used on currently
running missions. In one case that I was involved with, one of our
sources for schedule information changed over to require SSL. We
attempted to get the necessary software running on the machine that was
used for commanding, but after days of effort, we gave up. Instead, I
have a cron job running on another system to retrieve the schedules over
HTTPS, and then have the system pick up the file from our local server
using HTTP.

For other missions that have to go through change control, re-certifying
their workflows to use HTTPS could be a rather significant cost now and
in the future to deal with SSL patches.

HTTPS is not a security improvement for the hosts.

Although HTTPS makes it more difficult for an ISP to sniff someone's web
browsing, this feature should be properly weighed against all of the
security issues, as it can actually increase the attack surface and
cause other problems:

     * Flaws in SSL/TLS implementations have made it possible for third
       parties to dump information about acitivity (Heartbleed).

     * Flaws in SSL/TLS can create a false sense of security (POODLE, FREAK)

     * HTTPS would hide attacks from existing intrusion detection systems.

Many of the issues are specifically related to SSL3, but most servers
still enable this by default. It is quite possible that if forced to
meet a deadline, sysadmins may be rushed and use the defaults, making
their systems less safe.

Should there be a remote exploit, this could invalidate any of the
privacy improvements that may have been gained from switching to HTTPS.

In the past, we have taken servers offline as a preventative measure
against zero-day exploits that we could not conclusively prove that we
were immune to or could mitigate, as the alternative is multiple weeks
of rebuilding the server from the ground up and re-certifying it for use
should an exploit occur, or be suspected of having occurred. As such,
anything that increases the attack surface can decrease the availability
of the services that we provide to the public.

HTTPS is frequently implemented improperly

We also have the case of poorly implemented HTTPS systems in the US
federal government. I have stopped keeping track of the number of
certificates that I have encountered that are self-signed, signed by an
unknown CA, or expired. If certificates are not maintained, we risk
desensitizing the public to the issue and training them to automatically
trust the certificates without the appropriate level of scrutiny.

If webservers are not properly managed and insecure ciphers removed as
exploits are found against them, HTTPS may only offer the illusion of
privacy while leaving citizens vulnerable to monitoring from ISPs or
from other participants on unswitched networks such as wifi.

Just yesterday, I was given instructions for our new voicemail system,
which stated after giving the HTTPS URL to access it:

Note: You may receive a certificate error. Select "continue" to proceed
to the site.  With the relaxing of rules regarding disclosure of
information to third parties, government websites were allowed to use
services hosted externally. If these services don't support HTTPS, we
risk serving 'mixed' content back to the user -- which means we either
train them to ignore the warning if they want access to our content.

In conclusion:

Websites that use authentication or have personally identifiable
information about users of their systems should use HTTPS. There may be
other sites in which it would be appropriate for them to use HTTPS, but
there are still situations for which HTTP is a better choice.

In summary:

     1. Non-sensitive web traffic does exist.

     2. Moving to HTTPS has a non-trivial cost.

     3. HTTPS will reduce the availability of government information and
        services.

     4. HTTPS increases the risk for the maintainers of the servers.

     5. HTTPS is already implemented and broken on many federal
        websites.

     6. HTTPS may only offer an illusion of privacy while still being
        insecure.

     7. This proposal risks increasing the 'digital divide' for citizens
        who access the internet through schools, libraries or other filtered
        access points.  

     8. This proposal risks training citizens to ignore security warnings 
        from badly configured or maintained websites.

Although HTTPS may be better for citizen privacy, it actually increases
the risks for the maintainer of the servers and can require significant
changes in network architecture to mitigate those risks. There is a
non-trivial cost in banning HTTP, which could adversely affect the
distribution of information to the public.

Joe Hourclé (joseph.a.hourcle@nasa.gov)
Webserver & Database Administrator
Solar Data Analysis Center
Goddard Space Flight Center

#  distributed via <nettime>: no commercial use without permission
#  <nettime>  is a moderated mailing list for net criticism,
#  collaborative text filtering and cultural politics of the nets
#  more info: http://mx.kein.org/mailman/listinfo/nettime-l
#  archive: http://www.nettime.org contact: nettime@kein.org