TE website

As people have pointed out, it may be that HTTPS-only adoption has been so slow is because of the cost and difficulty of bringing up a Website with HTTPS. This is super easy in a Cloud instance, like AWS S3 and using Amazon's free digital certs.

Also, advertiser-revenue-driven Websites tend to do what their advertisers want. Not many advertisers seem to be pressing for their ads to be only served on HTTPS-only Websites.

And I am not, nor have I ever been, the owner of TE. I am just a long-time member that has the ability to ban spammers, trolls, flamers, and other policy-violators.

Verities wrote: »

I would be interested to see a study behind how many people are still using browsers that don't support HTTPS (let's say any that haven't been updated in 10+ years?); I just tried searching for one and came up empty.

I use the term mods as an all encompassing term for those that make decisions around here; I know you're the owner of TE.

I find some random old OSes and browsers going to my site too. This is the breakdown from my own site for the last month:

Heh... can't remember the last time I saw someone running around with an old RIM OS phone and yet they still pop up on my site. TE probably gets a crapton more traffic than some random blog and with larger geographic diversity than some random blog. There are probably parts of the world where someone can't afford anything more than a 10 year old phone that barely has a browser working.

oldOSes.jpg

oldbrowsers.jpg

shochan wrote: »

Can the moderators "EXTEND" the timeout while logged into the TE website?? It seems if it is idle 10mins it logs me off...ridiculous!

Personally, I have never had this problem but then again, I just check the "remember me" box on my trusted computers and never sign in again until I clear my cache on my browser

A lot of old devices are refurbs and end up in poor countries. Of course, this is all determined by User Agent strings, which can be easily changed. Anyone using an anon proxy and Firefox with User-Agent Switcher, uBlock Origin, NoScript, and private browsing mode can really screw up accurately tagging a user's browser fingerprint and geographical location.

the_Grinch

33mail.com would definitely be helpful if you wanted to have a different address for each website. Unlimited addresses and you can forward it to a central account, with the added benefit of destroying the address if you don't want it anymore.

Verities

@Grinch - I use 10minutemail for pretty much everything. If I ever need an account for something I set it up, click a link on an activation email, then save the user/pass in the browser. There are very few things I use a private email account for.

@Iris - Ok, so of all the browsers you linked, which ones don't support HTTPS?

@JD - I didn't know that you weren't the owner of TE. Its super easy to get HTTPS up (plenty of free documentation on DigitalOcean) and functional on Linux (from the Apache Web Server perspective):

1. Install httpd mod_ssl > generate Certificate Signing Request (CSR) with OpenSSH > copy private key to /etc/pki/tls/certs/private/

2. Submit CSR to CA (pay about $60) and receive SSL certificate > copy certificate to /etc/pki/tls/certs/

3. Adjust /etc/httpd/conf.d/ssl.conf to point to the proper SSL certificate location > start httpd > voila you now have an HTTPS web page.

If its that easy on Linux I'd imagine its even easier on vBulletin. In any case, is the idea behind not utilizing SSL to get this site out to countries who are so poor they can't afford to upgrade off Windows95 so they're using a super antiquated browser? Because if they can't afford that, how would they be able to afford an IT certification?

Interesting find of the day: https://www.eff.org/HTTPS-EVERYWHERE

Too much effort to find out or care. Simply stating there's a lot of old browsers, OSes, etc that browse my lil' old site.

Iris also pointed out to me that encrypted HTTPS tunnels are used to hide Malware transmission/communication. At least with an HTTP-only site all of the traffic can be transparently scanned for suspicious/malicious content and behavior. If it were my call, I would use HTTPS only for authentication and identification of TE, but not actual encryption of the in-transit content.

The HTTPS tunnel is between web server and browser; any malware if any will need to originate from TE web server. And most of us have end-point protection installed. If we have HTTP connection, a malicious actor can inject malicious scripts/malware mid-stream or steal authentication cookies to impersonate our account.

I rather we have the option to access the entire site either via HTTP and HTTPS.

Mike7 wrote: »

And most of us have end-point protection installed.

You have more faith in inexpensive, consumer-grade EPP software than I do.

Mike7 wrote: »

If we have HTTP connection, a malicious actor can inject malicious scripts/malware mid-stream or steal authentication cookies to impersonate our account.

You have less faith in your ISP than I have in mine.

JDMurray wrote: »

You have more faith in inexpensive, consumer-grade EPP software than I do.

I usually access TE from home. With HTTPS, malware (if any) can only come from TE web server. At work, they do SSL inspection so HTTPS does not matter. I did suggest providing option to choose between HTTP and HTTPS.

Is there currently any active scanning of suspicious/malicious content and behavior to TE? From work? WAF at web server? WAF do support HTTPS if installed on web server.

JDMurray wrote: »

You have less faith in your ISP than I have in mine.

I have less faith in other ISPs. The are 17 traceroute hops between me and TE.

Credentials stealing and session hijacking is a concern. What happens if we access TE via wireless? Heard of FireSheep? My GCIH instructor told us how his non-IT savvy grandma hacked into other people's Facebook and upload naughty pictures without his help.:D He only discovered it during her funeral.

Good debate BTW.

Mike7 - Glad you access it at home. Lots of people access it from work. In a highly secure workplace, there might be a requirement to decrypt traffic to make sure nothing is piggy backing into the work network. Since decryption costs money, I've seen many workplaces chose to block non-essential blogs and forums since than spend the money on decrypting the traffic. Also security admins without the budget to upgrade their firewall or appliance that does the decryption might likewise do this to stretch what they have.

Guess what, most inexpensive web filtering appliances only work with http. Without SSL inspection, they are blind to the site you are visiting. If I add "www.facebook.com" to block list, it blocks access to http://www.facebook.com but not https://www.facebook.com.

So you need to block by IP. Ever try blocking Facebook by its ever-changing IP?
What happens if I put a site behind CloudFlare where the IP is always changing and is shared with other legit sites?

I suggested allowing site to be accessible via http and https. It does not require much effort for your workplace firewall admin to limit TE access to http only. If it helps, have a separate https domain name say secure.techexams.net.

Without HTTPS, it is possible to hijack site admin credentials, extract entire user database and/or modify site to distribute malware to all TE visitors. That will be bad.

You can actually grab the SSL cert at the beginning of the exchange to typically see what site you're going to. You can even do this with NBAR2 on a router. That's how your Youtube, Facebook, etc traffic is categorized as such despite the fact that your router cannot decrypt it. Is it 100% accurate? Nope because things can change after that secure connection is established but it does give you a good indicator where that traffic is going to overall.

Give it a shot. Enable an NBAR2 pack on an ISR and give it a whirl.

Here I am going to HTTPS sites

Look, AVC sees Google Services, Youtube, and Facebook:

You can also grab the SSL common-name out of Netflow as well with NBAR2 turned on:

Lot of ways to skin a cat or at least make a good guess at what site that user is going to even without decrypting the traffic with inline solutions.

Sites.jpg

Application Visibility.jpg

SSL Common Name.jpg

BigAVC.jpg

I learned something today...

There is no in-transit information on TechExams.Net that is private except for the authentication process. The forging/spoofing of credentials to commandeer a member's account for impersonation is the real threat here and on a million other public Websites as well.

I'm saying this in case any TE members have a mistaken sense of security because of bBulletin's "Private Message" feature. Please do not use TE for storing any truly private information.

shochan

I suppose, I could check the box to remember me. It is a habit of mine of not saving login credentials on all websites I visit...regardless if the computer is public or private, I just don't do it.

Maybe TE set the timeout settings to keep their servers from being overloaded with users still logged in, idk...I would just like to be longer idle timeout - but again no big deal. They are going to do what they wanna do.

Verities

shochan wrote: »

I suppose, I could check the box to remember me. It is a habit of mine of not saving login credentials on all websites I visit...regardless if the computer is public or private, I just don't do it.

Maybe TE set the timeout settings to keep their servers from being overloaded with users still logged in, idk...I would just like to be longer idle timeout - but again no big deal. They are going to do what they wanna do.

No disrespect, TE is not exactly a work-related site. If I access it outside home, it is from my mobile and not from office internet. I assume most companies do have an internet usage policy as well.

I think we digress from the origin intent for SSL cert which is security and the risk of data breaches and malicious intent.
The case against SSL is accessibility.

How do we address the security risk and yet ensure broad access?
Will a separate secure HTTPS domain satisfy all parties?

Considering no one on this thread can make that decision or make any changes to this site, I can't say it would satisfy "all parties." While this is a fun conversation, none of us have the power to take any action either way.