Just realized. The only use of port 80 (providing it runs something like NginX/Apache) is (or, should be anyways) redirecting users from a non-secure connection to a secure one.

Poor port 80 😖

Or 8080 for Minecraft servers.

Port 80 is still in use: http://www.washingtontimes.com.
WTF?

@Almost They forgot to add 443. Even for subscriptions, newsletter, ...

@ewpratten I thought minecraft’s default was 25565

25565 is used by Minecraft, 8080 is often used to redirect internal webtraffic to another service (e.g. Gitlab CE)

@ewpratten or noob node.js developers who started their http-server without changing the default settings.

@linuxxx I like how you add your username as a tag. Without opening the rant I know it's from you.

@Siddharthkr93 Yeah idk partly took that from @jpichardo :)

Not sure I need my public dictionary feed encrypted.

I guess https is great for Google so only Google tracks what I search for and invades my privacy :->

Sometimes HTTPS is like putting a combination lock in your house on your bathroom door. Not always a good idea.

Don't forget, SSL costs money in server certificates, SSL accelerators for very busy server systems, and the extra trickle of battery from the mobile device. As the old bumper sticker said: Ass, Gas or Grass, nobody rides for free.

@calmyourtities sorry.. it is. I think I just have mine auto set to 8080.

@xcodesucks But...but...lets encrypt is free? :D

@xcodesucks With today's surveillance and ISP tracking it's a requirement imo.

Why not secure everything possible? Extra battery usage? Nope, with HTTP2 and https both enabled it's less resource intensive and loads faster.

Ever heard of letsencrypt? Also, Google will start showing websites without SSL/TLS a lot lower in the results next year. And it won't only be for sites with login stuff, it'll be for every site. Also both Firefox and chromium/chrome will add a default not-secure warning for every site visited without SSL.

As we saw last year and partly this year (I thought?), Verizon (US) put tracking pixels and other highly invasive persistent tracking stuff in every non https webpage going through its systems. That's just not okay and using SSL makes they can't do that on those pages.

(not a personal attack or something, just stating some facts and my opinion :))

@runfrodorun @jckimble am I right or not really by the way?

@linuxxx you're right. But you forgot the fact that anybody in the network can inject anything they want to your page if you just use http. exploits and phishing are two things that come to mind that can easily happen with using http

@jckimble True thing, thanks for the addition!

@runfrodorun Thank you, spot on.

I thought port 80 was for tunneling encrypted traffic to proxies, through firewalls?

That literally reminded me instantly of Internet Explorer 😂😂😂😂
M on devRant too much 😂😂😂

@ThoughtfulDev Yes, god bless LetsEncrypt folks but also, the 90 day thing... it's only completely free if your time is worth nothing... Imagine running a server that gets over a million hits a day, then adding on the SSL overhead. EEK. SSL is great but when it doesn't make sense (pubic pages at whitehouse.gov) it doesn't make sense.

@linuxxx Not taken as a personal attack but you do have to realize that every assembly instruction that is executed costs money. SSL overhead is not free.

@xcodesucks "overhead" please explain?

"Public data" - insecure connections can be used to manipulate data on the fly, inject tracking/exploitation shit and perform MiTM attacks.

@xcodesucks With hardware crypto acceleration its literally nothing. With http/2, https is actually faster than non https.

@linuxxx Sure, SSL denotes encryption. Encryption that is not present on HTTP sans S. That encryption is performed through floating point operations. Floating point co-processors used to take that load on the main CPU but now we all buy SSL Accelerators to handle the SSL at the server side:

(https://en.wikipedia.org/wiki/...).
"SSL acceleration (TLS acceleration) is a method of offloading processor-intensive public-key encryption for Transport Layer Security (TLS) and its predecessor Secure Sockets Layer (SSL) to a hardware accelerator."

Note "processor-intensive". These components are not free. If my web server is taking say 50M hits a day (file requests) and each hit goes through a process of encryption, send, decryption. That's overhead!

@xcodesucks Gonna call someone for this one. @runfrodorun halp :P

@xcodesucks I'll still take overhead over posaible personal security though.

@xcodesucks @linuxxx in cases where their is no pii(personal identifing information) on the connection there is no need for https. But seeing that search engines are starting to penalise non https sites you should have it even then. But besides that there is other reasons you should always enable https like to prevent injection and mitm attacks.

But as a side note there are times https is faster that http
https://www.httpvshttps.com

@linuxxx there is more data with SSL/TLS crypto so how could it be faster? More data == slower finish on same speed connection. Maybe I misunderstood what is faster?

@linuxxx To inject data on the fly, you have to be in the middle... and that requires controlling IP routers between the source and the target. Much easier to spearphish / Trojan through a similar link. And that is where SSL and TLS cannot help.

@PerfectAsshole (great handle) Not aware of the penalization on HTTP. More info?

@xcodesucks With http2 it's actually faster. Only apple doesn't integrate with that. Source: I work at a hosting company and deal with ssl daily.

@xcodesucks Oh and take a look at the NSA program called Quantum Insert ( thought that was the name?) Also, its known that isp's insert tracking shit into unencrypted connections.

If you don't use SSL, I'll assume you don't give a fuck about your users' security.

@xcodesucks I'm too lazy to search for the page that I found it on at the moment. Google started doing it last year where https sites were given better rankings, chrome starting last month is starting to mark all http sites as insecure.

As for the other two questions. For why ssl is faster, ssl is using compression algos in connection to shrink the size. And for the injection part with http at any point between the server and your computer code can be injected or at very worse dns records can be changed to make you hit another server. While in the worse case can happen with https if hsts is enabled on a website you will get a blaring warning.

@PerfectAsshole Thank you.

@runfrodorun every execution of an instruction, regardless of the type of processor it runs on, requires a cycle of the clock. Some are run in parallel but it doesn't matter, they take some amount of CPU/FPU/ALU time somewhere.

The end result is that you can do it linearly or do it in parallel. Linear takes longer chronologically and costs less in hardware. Parallel means more hardware and shorter chronological time. The end result is that both ways take the same amount of CPU, ALU or FPU time.

I measure my code efficiency in terms of CPU clock cycles, not the desk clock. Sorry for the confusion.

So SSL/TLS can either cost more money and take less chronological time or cost less money and take more chronological time. No matter how you stack it, Time == Money. No such thing as a free ride.

And btw, it is an old school trick to use really fast FPUs to do integer math in parallel to the CPU, & offload the CPU. FPUs are inexpensive & great for real-time microcontroller SBCs.

@runfrodorun You never fucking fail to amaze me.

@runfrodorun :-) a free clock cycle... free power?

All kidding aside, the nitty gritty is that the AES encryption decryption code here (https://tls.mbed.org/aes-source-cod...) never gets run if it is HTTP.

Running extra code is slower than not running extra code. If you run the extra code in parallel so your chronological time is not impacted, you impact your wallet by buying more components.

Wikipedia, first sentence. https://en.wikipedia.org/wiki/...

Same story since the beginning of time (January 1, 1904 :-) no such thing as a free ride

@linuxxx re: runfrodorun, definitely intrigued! :-)

@runfrodorun Yes, I have coded directly to DSPs in hex. :-)

I have been around through CISC, then RISC, then CISC, then RISC. It is all a joke. More little instructions to to the job of one or one big instruction to do the job of many small. We are all still a slave to the oscillator.

I know exactly how instructions can operate across the clock cycles. bit wise operators are my friend.

Toss your favorite timing diagram up. Show me how the CPU gets a free instruction that can calculate AES encryption and not cause any other instructions to wait, cause no impact any other code that may want that same capability to do something more useful than encrypt public marketing propaganda. :-)

@runfrodorun Once I thought I was wrong, but I was mistaken.

@runfrodorun Not confused at all. You are arguing speed of execution and I am simply watching that.

Your argument is "well if I put a bigger engine in the Escort, it goes faster and the speed is free".

Put another way, you are arguing that putting massive amounts of needless add operations in your code not only speeds your code up, but can be done at no monetary cost, and at no detriment to any other code running in parallel vying for the same processing unit for some other operation.

This is where practical experience trumps being well read.

Bring your timing diagram and an assembly code example of your free ride.

@runfrodorun i know alot generally about computers but i just about always learn something new from your comments

@xcodesucks from what I'm reading he's arguing that since its already there why not use it. So more like saying if you have a backhoe running why use a shovel

@PerfectAsshole It might be a matter of perspective

@runfrodorun may be operating under the assumption that the processor is doing nothing so why not have it do encryption or decryption calculations.

My perspective is from a pre-emptive realtime multithreading nondeterministic state machine perspective... the processor is always overloaded and every operation is performed at the detriment of some other operation somewhere.

There is incredible bloat in software these days and it stems from the believe that all of the memory and all of the CPU can make up for inefficiency of code. Ain't true.

@PerfectAsshole psst, is runfrodorun a she or a he? And for that matter, which am I?

:-) "they".

Ain't semi-anonymity great!

@xcodesucks i agree with you on the fact that alot of devs just write resource intensive code for no damn reason cause it gripes my ass.

@xcodesucks he's a guy. And I'm hedging my bets on you being a guy also based on the way you are writing.

Not impressed yet? Iphone app dev, between 24-33

@runfrodorun you are missing the point. It does not matter how many instructions are packed into one clock cycle. If one instruction is waiting for another and the one that is being executed is not needed, then you have a "cost".

i7 is a very expensive component, the single most expensive component in most laptops short of the screen. You are paying for needless AES encryption when your system could be doing something else with those instructions.

If a small component device like the Apple Watch, with limited battery, has to do processor intensive AES, there is a cost. You have to put it on the charger more often.

Simple laws of physics and frankly thermodynamics.

Sorry you don't understand. Maybe when you have do product development against a limited budget that you are in charge of, you will remember this.

@PerfectAsshole guilty and partially guilty :-)