What's up with the anti-https shills?

What's up with the anti-https shills?

Is https really going to steal your precious bodily fluid or are they just shills/lolcows?

Other urls found in this thread:

tools.ietf.org/html/rfc2818#section-3.1
developer.mozilla.org/en-US/docs/Web/HTTP/Public_Key_Pinning
twitter.com/NSFWRedditImage

they just have no clue

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 think it just prevents a MITM from monitoring what you are doing.

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?

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".

...

Did you miss
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?

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.

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

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

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

https is shit go fuck yourself

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

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

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

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, tools.ietf.org/html/rfc2818#section-3.1

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.

No big deal on modern devices but regular http should not be deprecated for the illusion of extra security

Attached: Personal_System_2_Series_of_Computers.png (800x415, 346.58K)

found the paranoid brainlet

it's even worse than planned obsolescence

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

Attached: taketh away.png (495x495, 40.53K)

The old computers aren't all power-hungry. Pic uses less power than any modern laptop or smartphone for example.
Anyway not everything is about power consumption. It's also nice to have hobbies and have a "fuck off" computer that isn't full of modern botnet and shitware.

Attached: Radio_Shack_TRS-80_Model_100.jpg (1490x1054, 802.63K)

...

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.

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.

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.

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.

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.

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

1) Mutual auth is a thing
2) Normally you get the fingerprint beforehand if the server operator is not a dumbass

free certificates are a thing

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.

That's what I meant when I said:

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.

I would use HTTPS if I were managing user logins and user data, but to serve an HTML document I just don't see the point.

If I were to use HTTPS I would use a self-signed certificate. I find the whole procedure of the user personally adding my certificate alot more secure than blindly trusting an embedded list of CAs decided by the browser vendor. The user would know if the certificate changed and be alert which they rightfully should be.

I'm not a big business and I think that not having users who get scared or think it is too complicated to handle security is a feature. I want them to know about HTTPS and certificates. That way they might even want to start logging in using their own certificates.

Attached: ecaeb80269b09ea23669bf00837dc8639d453f82.png (740x221, 42.76K)

>>/reddit/
see you are leaving your visitors vulnerable to having bad stuff injected into the page, including a mitm modifying the page to look bad.
...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.
???

...

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.

Uhm.. not sure if the user was compromised or my server was. HTTPS does not secure your site from having bad stuff injected into it, if your server is insecure your server is insecure. If you have enough control over "the middle", you might as well have that control and get a signed certificate with letsencrypt. Now all users think they are secure, because the browser say so. If the user is compromised no HTTPS is going to help them.

That is true. If they are already compromised on first visit nothing is going to help them. As to the question on how to give them the certificate.. I'd choose carrier pidgin.

Your browser can store your own personal keys and you can use them to log into websites. No sites care because.. they don't.

If we are to discuss this seriously, you need to present a thought attack. Where is the MITM? Without knowing the attack, it's impossible to present valid arguments for either side. I can't guess what attacks you are thinking of.

Attached: 2340.jpg (740x586, 150.02K)

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
Although I do believe there should be some way to allow just encrypted traffic without authentication.

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

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

In this case the connection between them is.
The communication channel is secure.
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.

this is optional

One easy extension which is called HTTPS Everywhere

so you choose>>944583
autism, m-kay
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.

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.

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.

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

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.

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.

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

Devuan too and I'm glad they have.

I didn't consent to it.

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

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?

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

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

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

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

Different user. 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.

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.

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

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

Certificate pinning is a very shitty solution.

What about certificate transparency

...

Exactly, you would notice it wasn't logged.

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

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.

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

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:
developer.mozilla.org/en-US/docs/Web/HTTP/Public_Key_Pinning

lol no its one of the shittiest

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

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.

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.

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.