/tech/ - Technology★

>>944197 (OP)

they just have no clue

>>944197 (OP)

Google and Mozilla flat out block non https connections now. NOTHING gets pushed this hard by kikes without ulterior motives. I don't fucking care if my traffic to something like wikipedia is encrypted or not.

It's mostly from people who have no clue what https means. Most people like >>944205 think it just prevents a MITM from monitoring what you are doing.

>>944208

I look forward to your informed explanation of how I'm wrong. It couldn't be that you're just a retarded teenager blowing smoke, could it?

>>944210

HTTPS also protects against a MITM from modifying the data. An attacker can change the contents of the Wikipedia enabled. If you have javascript enabled they can run arbitrary code on your machine, even it you only have scripts from wikipedia allowed. They can also trivially insert ads into the page in which your adblocker won't automatically block.

Because any agency that wants to break it can and will? The idea of PKI is, and always will be, a farce. It's better than plain http; sure. But it's far from "secure".

>>944217

<A super government agency can break it, so I should just leave everything unprotected so everyone can break it.

>>944223

Did you miss

>It's better than plain http; sure.

I will continue to only use https websites; but thinking your https connection is "secure" for even a second is something to laugh at.

What is the deal with this https-only jew cult?

>>944210

He would've made you look like less of an idiot if it weren't for that unnecessary 2nd sentence.

Polite sage for off-topic.

>>944230

you're right. I need to have some introspection about this.

>>944208

>think it just prevents a MITM from monitoring what you are doing.

Https and other integrity protocols were never designed to make the content you browser to be private. Like >>944215 said it protect against against modifying the data. For example without it modification of scripts or simply injecting new ones could be possible.

>>944217

Imo since the letsencrypt movement I'm persuaded that someone found out a exploit in HTTPS.

>>944197 (OP)

https is shit go fuck yourself

>>944208

I don't see how relying on (((CA))) would make me any safer.

>>944314

You fucking mongoloid, TLS doesn't need a CA. my server doesn't rely on a CA and I still run HTTP over TLS.

>>944314

Yes, the CA model is flawed. Things like HPKP and Certificate Transparency address some of the flaws.

>>944328

lol @ you

the whole point of https is to avoid mitm, how would you do that without verifying a server's identity?

here's some actual documentation, you dumb sperg, https://tools.ietf.org/html/rfc2818#section-3.1

>>944335

It does still prevent MITM. It's like how SSH works. No one can see what your sending to the server. If you want to prove you are talking to the real server than you need to get the server's public key through a secure side channel.

>>944205

found the paranoid brainlet

>>944345

>wasting power on ancient garbage-tier inefficient computing devices

it's even worse than planned obsolescence

>>944338

it doesn't if you don't verify its identity and you don't have a secure side channel unless you hang out with the site owner in person

why are you pretending to be dumb so hard

>>944345

<browsing the internet gets slower for older devices

If you need it to be fast then you will want to upgrade.

>illusion of extra security

It's not an illusion. Else prove it. If you can, you will become very famous.

>>944350

No one can break into what you are sending back and forth with the server.

>you don't have a secure side channel unless you hang out with the site owner in person

This is why people hope their first connection to a ssh server is to the server itself and not just someone else's server.

>>944353

Just have the modem you hook that up be a https <-> http proxy.

>>944355

>No one can break into what you are sending back and forth with the server.

You first need to know you're talking to the server to be sure you're sending stuff back and forth to it. If there was a Man In The Middle who was pretending he's the server you got no way of knowing.

>>944338

>If you want to prove you are talking to the real server than you need to get the server's public key

No shit, that's the purpose and flaw of CA. You need to somehow verify that the key sent by the server is the one that's actually supposed to be.

You put all your trust into CA, you can get screwed over without even being aware.

>>944355

>This is why people hope their first connection to a ssh server is to the server itself and not just someone else's server.

You still don't make any sense. Do you understand the context?

HTTPS is mostly secure. It's just TLS after all. What's not as secure is the CA mafia model; you could use your own self signed certs anyway if you don't mind getting ugly "WARNING: YOU ARE BEING LITERALLY RAPED BY THIS SERVER! USE HTTP INSTEAD!!!" warnings. Still, the CA model offers more security than nothing, but it's still very scummy, business-wise.

(((They))) profit from selling certificates.

>>944350

>unless you hang out with the site owner in person

Exactly. The only people who use my server are the people i know in real life. Any other visitor i really couldn't care less if they got mitm'd because the sit isn't for them.

>>944364

>if you don't mind getting ugly "WARNING: YOU ARE BEING LITERALLY RAPED BY THIS SERVER! USE HTTP INSTEAD!!!" warnings

> USE HTTP INSTEAD

LOL

you have no clue

and in this case it's no better than unencrypted anyway, because you can't tell legit certificate from a spoofed one. unless you are also the only user of your website or all users are your IRL buddies.

>>944389

You know, web exists not only for this kind of autism. Some websites (actually most) are meant to be used by any random person.

>>944355

>This is why people hope their first connection to a ssh server is to the server itself

1) Mutual auth is a thing

2) Normally you get the fingerprint beforehand if the server operator is not a dumbass

>>944382

free certificates are a thing

>>944353

>The old computers aren't all power-hungry

They are all less power efficient though.

Same amount of computation will take more energy even if energy consumed per minute is smaller. So in the end you waste both energy and time.

>>944402

>Normally you get the fingerprint beforehand if the server operator is not a dumbass

That's what I meant when I said:

>If you want to prove you are talking to the real server than you need to get the server's public key through a secure side channel.

>>944399

>you have no clue

Browsers encourage this behaviour by showing the (very important in the cases that matter) warning when going into the HTTPS version of the site, and then not tainting future HTTP connections to that domain and showing it as well in those. So your average somewhat savvy user but without much knowledge or consideration of security will understand the problem is HTTPS, and will downgrade to HTTP instead of pressing the terribly hidden "permanently inject AIDS to this computer". Since HTTP does not show the warning, they will just continue browsing.

Anyway, most of the time, self-signed certificates are just a problem caused by incompetent or cheapskate sysadmins. If it's your first connection to a site and it already complains about it, unless you have some non-gubernamental (because the government could already tamper CA certificates) agent monitoring you, which is extremely unlikely, it probably is not a problem. If you can verify the fingerprint, like when connecting to your own private website, you should be fairly safe.

>>944591

<xkcd

>>>/reddit/

>I just don't see the point.

see >>944215 you are leaving your visitors vulnerable to having bad stuff injected into the page, including a mitm modifying the page to look bad.

>If I were to use HTTPS I would use a self-signed certificate

...and how do you plan on securely giving everyone your correct public key. If they don't know your private key, the could accept a certificate of a mitm on accident.

>That way they might even want to start logging in using their own certificates.

???

>>944205

>a more secure alternative is making certain companies block the less secure protocol

>wtf why

>>944598

How easy is it for someone to MITM without having access to the router, LAN, whatever?

good bait op

I was shaking my head when I was reading through the debian mailing list archives yesterday and some faggot maintainer was demanding https mirrors to remove "debian" from their url purely because they can't point the domain to another server in case of a failure. Well oh gee, who could have thought about having multiple https mirrors in case one of them goes down or just fucking distributing certificates across the servers?

If only World Wide Web had a mechanism for cryptographic page and document signing, then there would never be need for https for 99% of the time. First, https breaks caching proxies, instead we we have cuckflare to geo-distribute and also tamper with content. HTTPS doesn't prevent you from downloading a malicious page from the server because everything it checks is certificate's validity, and this certificate is stored on a server, a rented virtual server on some one's computer, not even website author's machine. The certificate in fact can be on any of the computers between you and the supposed target server, and you won't know because everything is okay, the certificate is "valid", only it is either stolen or assigned by malicious authority to CIA niggers. Imagine going to a guy's blog or news website. You see https and think everything is fine, the content is intact, The reality is, anyone with physical or remote access to server can tamper with content without author's notice and alter audience's opinions through this. Content signing would prevent such situations. A signed document is either valid or invalid, and if the author is not an idiot, compromising his signing keys is a very hard task compared to keys on a virtual machine is data center. This is why repositories never use https, it's useless because content of repositories is not secret, anyone can see what software they store, hiding behind encryption is pointless because https has no traffic obfuscation and it is really easy to see what exact package you are downloading just by observing traffic, and package signing prevents MITM tampering if you got developers keys from a trusted source.

>WARNING: YOU ARE BEING LITERALLY RAPED BY THIS SERVER! USE HTTP INSTEAD!!!" warnings

Those exist because if there's something wrong with an HTTPS connection to a mainstream site (e.g. online bank, faceberg), they prefer people to think they're being MiTM'd rather than risk it. If they did the same with HTTP, they would be fucking over anyone who hasn't yet subscribed to the CA racket.

Also, consider that

>invalid cert = should be fixed ASAP. >http = working normally

Although I do believe there should be some way to allow just encrypted traffic without authentication.

>>944197 (OP)

>What's up with the anti-https shills?

It's not HTTPS that's the problem. It's the certificate authorities.

>I want some evil fuckos to control what keys are used for my website

>>944602

Well you have to control somewhere in the middle to MITM.

>>944627

>not sure if the user was compromised or my server was

In this case the connection between them is.

>Now all users think they are secure

The communication channel is secure.

>No sites care because.. they don't

Some sites do. Though most sites which use it are not meant for the public.

Connections to https trigger certificate check with few (((issuers))). Spying on everyone without need of being mitm.

>>944725

this is optional

>>944631

>Although I do believe there should be some way to allow just encrypted traffic without authentication.

One easy extension which is called HTTPS Everywhere

>>944627

>.. I'd choose carrier pidgin

so you choose>>944583

autism, m-kay

>HTTP does not show the warning

it will

now it shows a lesser warning

the problem is not HTTPS, the problem is just shitty default behavior of web browsers. which is, again, solved by 1 simple extension.

>>944625

>This is why repositories never use https, it's useless because

An adversary can prevent specific software updates from being delivered on unencrypted connections. With a TLS encrypted connection however, the adversary can either choose to outright block connections or allow all of them, ensuring that packages are not delayed from being delivered. An .onion repository is the better than all the options above but only Debian has it as far as I'm concerned.

>>944205

I agree. Mozilla specifically has made many anti-user decisions over the years, so if this isn't suspicious to someone, he must be pretty naive.

By the way, I hate the "this site has an invalid certificate - back to safety!" crap. Fuck off, if I want to connect to an "unsafe" site I should be able to...maybe this is the point.

>>944892

Also, cloudflare makes HTTPs actually unsafe - since it's a mitm that isn't detected...

>>944899

Cloudflare is consensual MITM. Website owners accept the risks when they choose such CDN. One might say that hosting website not from your own computer is MITM too, depends on threat model. Cloudflare is good enough for them because distributed denial of service attacks exist.

>>944884

If your local government or ISP went the path of fucking with Linux updates after all, there is a non-zero probability of them already having a capable enough DPI box that observes encrypted https traffic patterns and detects "wrong" packages by their size on the fly. TLS has no anti-DPI obfuscation! Using hidden service is probably the most safe of them all, as Tor has some basic obfuscation between client and bridge.

>>944892

HSTS makes it impossible to connect to a broken site from server's side.

>>944884

Devuan too and I'm glad they have.

>>944956

>Cloudflare is consensual MITM. Website owners accept the risks when they choose such CDN.

I didn't consent to it.

>>944328

and all you have is a bloated as fuck, buggy, roundabout way of making a secure connection. you could literally just use some plain libraries providing primitives with the appropriate padding/modes etc and would be better off

>>944899

HTTPS was always unsafe since any of the 500 CAs/intermediaries could just forge their own cert and pwn your connection

Does any of you know a way to save certificate fingerprint along with link to a site when bookmarking it? Any firefox addons for that?

>connect to 8ch.net

>https is good and signed by cuckflare

>try the IP

>no https. warning that cuckflare may try to steal my information

lol I never realised I'm actually on some other site this entire time

>>946887

use tor / the direct ip if you want to avoid MITMflare.

>>944832

No, this is default, and actually needed to keep safe, so 99,99% of cases.

>>946489

I'm not sure I understand. What is your rationale?

>>947030

Different anon. Certificate pinning I suppose so even an entity like a certificate authority cannot arbitrarily craft new certs to mount attacks against specific people, but this kind of shit is rather something that concerns people like Assange so I can't see how it is necessary for ordinary people. Correct me if I'm wrong though.

>>947040

Oh yeah let's throw real security out the window because "it only concerns assange". A CA could MITM 1 million bank users until someone notices. If these people had the actual public key of their bank instead of some vague bullshit (domain name), this wouldn't be a possible attack.

>inb4 hurr durr people would notice the attack

>inb4 hurr durr bank would reverse transactions

it doesn't matter, what i described was the most simple example of the attack. no matter how you slice it, this attack will always exist as long as we use fake crypto like relying on X509 to tell us what "the real public key" is

>>951152

>A CA could MITM 1 million bank users until someone notices

Did you not read the post you replied to. Certificate pinning aims to help solve that issue.

>>951446

Certificate pinning is a very shitty solution.

>>951456

What about certificate transparency

>>951484

>make broken backdoorable encryption

>be "transparent" around it

>yes goy look how transparent we are it's 2018 XDDD

>>951446

see >>945871

>>951544

What does that post have to do with what I said?

>>951829

using cert pinning is just an admitting that X.509 is fucking stupid. now can the web shotting niggers fuck off this board and stop asking stupid questions? nobody fucking cares about HTTPS. even your average tech hipster sitting in starbucks with a mac these days knows HTTPS is shit due to the heartbleed marketing campaign

>>951844

That posted said using https without a certificate was stupid.

>>951484

You mean that part where you just hope they don't publish certs without telling?

>>951881

You could check if they didn't tell

>>944205

>My browser wants me to go fully encrypted

>SO 100% UNENCRYPTED MUST BE SAFER!

Nigger, you just went full retard.

The worst shit will be some CA shilling crap.

<If every site uses HTTPS then people are reliant on centralised certificate authorities.

<If browsers can only access HTTPS then you can massively impact how popular HTTP sites are.

<Eventually there will be a push for only "official" certificate authority's regulated strictly by governments. This effectively controls information dissemination.

>>952288

It's been 30 years or so and no such push can or will exist.

>>952180

no, you can't, because it wouldn't be logged anywhere

>>952670

Exactly, you would notice it wasn't logged.

>>952749

and where do you get that list? o wait you get that list from some cert authority

>>952754

Websites pin their certs to Firefox when you make a connection with them for the first time and if memory serves right the certs persist between 2 weeks and a month. So in practice if you don't get a forged cert for the first time you won't get it for the foreseeable future. FFS read into topics you are making a comment on.

>>952813

You must of missed the part where cert pinning is a piece of shit solution with massive numbers of drawbacks.

>>952814

It's the best solution second to actually meeting the website owners in real life and getting their public key. The current system sure does have drawbacks but I'm not aware of better solutions. Let's take .onion domains for example. Since you have to build a trust chain with CAs to discover .onion domains (people copy paste .onion addresses on clearweb so you can discover them) even the whole authenticity of hidden services depends on CAs. This is the same for eepsites. But I would like to hear your solution to this problem.

Also, here is the automatic cert pinning I'm talking about in my previous post:

https://developer.mozilla.org/en-US/docs/Web/HTTP/Public_Key_Pinning

>>952822

>It's the best solution second to actually meeting the website owners in real life and getting their public key.

lol no its one of the shittiest

>>952823

as he's said, what's your alternative?

>>944205

The System is pushing for HTTPS because it doesn't want the competition to get that delicious user data. So they're pushing for the right thing, but for the wrong reasons.

>>952850

Not fucking using a system that allows a bad actor to hold my web traffic for ransom - a scenario that is a lot more likely to affect me than CA compromise affecting me.

>>952850

CAs were a mistake. It'd be much more secure against the real threats today if the browser just remembered and trusted the key sent with no authentication the first time you encountered it and flagged conflicting keys thereafter.

To spy undetected in such a system, the government would not only have to catch that first-use (possibly before they knew they wanted to target you) but they'd have to ensure you never access the site through any channel they don't control as you'd immediately be alerted to a key forgery, they'd need to continue to re-forge keys as they expire for as long as you continue to visit the site, and they'd need to hope the fake key that has to be stored on your device long term is never checked for forgeries by anything.

Today, if they want to spy on you you'd likely not catch it as the browser would quietly take the fake key during that session and later return to using the real key leaving no trace. CAs make that extremely easy.