Recruiters are getting smarter

THEN AT LEAST MAKE IT A FUCKING HTTPS LINK MOTHER OF GOD 😡

@linuxxx facts

@anyhus what do you mean exactly? 😅

@linuxxx that what you said is true, http is stupid and not secure

@anyhus Ah fair enough, glad you're agreeing with me :)

@linuxxx if I weren't you should throw me off at cliff... Or maybe just explain to me why I'd be so idiotic

@anyhus Okay I'll remember that xD

Yep. Definitely must be https to get a recruiter's email id off of a "contact us" page.

@shaji it's still good always

Oh wow. I just read "Show and hire lawyers" in the screenshot. Way to early this morning. Or just an association with "smart recruiters"?

The funniest thing about this is the fact you think i recruiter did this, they don't do work silly.

@Jop- In seriousness I think it does. But I simply think that everything (website) needs to be HTTPS. And next to that, it's easy as hell to setup!

@Jop- Apart from a slightly higher cpu usage and the need to obtain certificate, what drawbacks do you have in mind?

Ssl-ing everything (even public info) has its goals - ie. it makes it harder to block encrypted traffic, other encrypted traffic doesn't stand out as much and no one can track pages you visit by sniffing your connection.

@nblackburn good point, a recruiter definitely asked for it though

@shb743 But how can you be sure that nothing's been tampered with or no tracking shit has been injected along the way with non-secure connections? Or at a higher level maybe even exploit kits being used?
Is it common? No. Does https prevent that shit? Yes.

@perfectasshole

@shb743 oh and with the new http (http/2), https actually speeds everything up. Yeah, as in, a fact, not an opinion.

@shb743 @linuxxx mitmproxy, burp, and dnsmasq are 3 reasons why https with hsts should be used

@shb743 I'm afraid that it wouldn't. The handshake/key exchange is still there plus you still have to generate hashes for the whole content. IIRC the handshake is the slowest part of the ssl/tls connection while encryption is rather fast (and often hardware accelerated).

When working with dynamic pages you'd probably have to start splitting them into smaller chunks for hashing or make the user wait till server generates and hashes the whole page (read as: make them stare at a white screen for a few seconds, which is bad).

@shb743 If the content wasn't encrypted it would be enough to sign the hash.

When working with SSL/TLS you don't really need that many handshakes as you can reuse connection. Your solution for dynamic pages (generate segment, hash, sign/encrypt hash) might be actually slower than SSL/TLS as it requires more operations per segment. Even if SSL/TLS would be slightly slower, it still has many more features that are worth the additional time.

@shb743 But you'd then want to hash it and check that hash client side or something? If that's a yes, how can you be sure that the hash hasn't been tampered with? It's send over a non-ssl connection anyways.

@shb743 Reusable TLS connections are supported on most systems and they work just fine. Using or not using them is a simple matter of technical decision.

Keep in mind that you are computing hash first and only then encrypting/signing it. With pure encryption you are often using hardware backed algorithm that encrypts chunks of data (as it is being sent) and not the whole file at once.

That solution (minus signed hashes) already exists - you can often choose if you connect through http or https ;) However, as we have already pointed out, making SSL/TLS optional actually weakens its benefits.

@linuxxx The hash should be signed/encrypted using private key. So we are somewhat coming full circle and introducing key exchange/central key authority into equation ;)

@tnnn Don't know much about this part so let's call in (if you know a lot about it, I'm not trying to debunk your argument or anything or try to say that you're wrong but I don't know you well so gonna tag someone who I know/trust pretty well :)) @PerfectAsshole

@linuxxx I believe you misunderstood me. I was only trying to clarify @shb743 idea. From purely technical point of view it might work. However (from architectural point of view), I believe that we are getting too close to what TLS offers while loosing many of its advantages for little gain.

@tnnn Not sure if I understand you haha. Imo just use HTTPS everywhere :)