Is it really ok not to use HTTPS for serving images on your website?

t. IETF TLS WG

No, absolutely not. There is no acceptable use for plaintext HTTP in 2018, in the same way you shouldn't use Telnet for anything either.

>thumbnail is at i.4cdn.org/g/1536491261300s.jpg
Even moot - nay, even Hiroshimoot, has to do this, not least because you won't get the massive HTTP/2.0 benefit (for a site like this!) via a plaintext connection, because all mainstream browsers agreed not to implement HTTP/2.0 over plaintext.

Now when you're sitting in the coffee shop all of your images are goatse, because you remembered confidentiality but forgot about integrity. Well done. No, it should all be HTTPS, always.

>There's no valid reason not to.
caching

I said a valid reason.

server load

AES-NI has been a thing for nearly a decade. TLS is not burdensome in 2018. Stop using a Pentium 2 as your webserver.

>Stop using a Pentium 2 as your webserver.
don't tell me what to do

I can see that

but why aren't the boards in HTTPS?

Your computer can cache HTTPS delivered content, though.
>b-but my ISP cache proxy!
Fuck them.

>buying into the certificate jew
HTTPS was mistake. Use only HTTP.

this is no longer a valid objection now that Lets Encrypt exists.

They are, but you're not forced to use it

Just sign your own certs.
>b-but the browser warnings!
Fuck them.

Attached: cnujKDQ[1].png (485x34, 3K)

HTTPS should only be used for things that need to be encrypted.
For everything else it's a waste of bandwidth. HTTP can be locally cached by an ISP, increasing speed and saving bandwidth at both the source and destination.
HTTPS Everywhere is an NSA plant in the EFF.

You're full of shit.

If only "sensitive" information is encrypted, then sending encrypted traffic advertises that you're doing something sensitive, which is a very bad thing to do. If everything is encrypted, the "sensitive" traffic looks the same as the giant masses of other traffic, and anyone trying to attack it (or just block it) will be at a loss. Furthermore, who decides what "needs" to be encrypted? ISPs have already shown that they'll maliciously tamper with whatever they can. Comcast injects JS into unencrypted pages. Verizon got caught some years ago inserting tracking headers and selling the resultant data. Presumably they and many others besides also engage in passive monitoring of unencrypted traffic, which is pretty much undetectable. TLS kills all this shit dead.

Losing caching is a trivial price to pay to gain these advantages.

yeah if their certbot would work

>Losing caching is a trivial price to pay to gain these advantages.

Not when you are bandwidth restricted. It is an huge price.
How many gigabytes a month is the google logo downloaded by your ISP?
Imagine a user had to pay a dollar per gigabyte.
I've seen people post here that they pay $20 a gigabyte.
HTTPS prevents local caching, and that can become expensive.

Your argument about obfuscation is dumb. It goes both ways. You're also implying encrypted data is easily decrypted.
It's not.

Even if it is stored, it's uselss, if in fact, in the future, it is decrypted, because it's old. Encryption is only useful for 'live' sessions.

That's an argument against bloated websites, not against TLS. Using caching is solving the wrong problem.

HTTPS only matters for passwords and sensitive data. Public stuff anyone can see isn't relevant. We know from Snowden's leaks that the government can decrypt CA certs.

MITM can happen for static sites that is publicly accessible.

privateinternetaccess.com/blog/2016/12/comcast-still-uses-mitm-javascript-injection-serve-unwanted-ads-messages/

certificate transparency drastically increases the cost of using a compromised CA. Pretty much as soon as you try to use your bogus certs they'll get noticed, and people will figure out that the CA got hacked. What used to be an expensive but powerful and general interception capability is now just as expensive, but something that works at most once before it winds up on the front page of security blogs. Three-letter agencies really hate when that happens.

Depends on if the image, url, or path, can be considered information leakage.

Maybe it's ok for your banner or theme images. Maybe it's ok for product images. But maybe not. The problem is that all the cases where it's ok to serve images over http are exceptions, and not the standard case. The more exceptions you have, the easier it is to miss problems. Especially when there are incremental changes over time.

>what is letsencrypt

fuck off CIA shill
HTTPS is compromised and botnet

Attached: 1521618229957.jpg (1024x1024, 131K)

>not using acmetool