Incorrect Information in "Does HTTPS REALLY Keep You Safe?"

[LAwLz]

I saw that LTT had released a video called "Does HTTPS REALLY Keep You Safe?" and as a network and security consultant who has been vocal about criticizing the huge amount of misinformation in LTT videos, I felt like this was a good opportunity to check if LTT is actually delivering on their promise of higher quality videos with less misinformation in them.

 

Here are the issues I found in the video:

 

 

At 0:40 the video states:

Quote

and yes, there are ways that your employer could still look at your web traffic [even if HTTPS is used] such as through a proxy, but I am sure all of you are on your best behavior on the job.

I think it is important to note that it would only be possible for a proxy to decrypt HTTPS traffic if the employer somehow got a root certificate onto the computer you're using to browse the web. This is the case in a lot of corporate environments where the computer is managed by an IT department, but I think it is important to note that it's not like a proxy can magically decrypt traffic transparently if HTTPS is used. The manager of the proxy has to either tamper directly with your device to make it trust the proxy, or it will throw up certificate errors and warn you that your traffic is about to be decrypted.

Some programs are also using what's called certificate pinning, which means that you can not put up a proxy and decrypt the traffic even if the IT administrator puts a root certificate onto your device. One notable example that uses this is Dropbox. You can not do a MITM on a Dropbox client trying to connect to Dropbox's servers. No proxy, firewall, or other thing can decrypt that traffic in transit.

 

 

 

There are several points in the video where the word "URL" is used when "domain" would have been a better word. This might sound like nitpicking, but this is actually a very important distinction when talking about HTTPS because HTTPS does not encrypt the domain portion of a URL. It does however encrypt parts of the URL like the path, query, fragment, and so on. 

Here are the timestamps where this mislabeling happens:

Quote

1:13 although this might be a bit nitpicky because it is true, but I feel like it was accidentally true and could still be a bit misleading.

3:50 This is like the mention at 1:13 technically correct, but I feel like it was accidental. The correct terminology would be domain in that cases, even though the URL contains the domain so what is said is in a way true.

4:10 This is where it is very wrong to say URL instead of domain. More on this later.

 

 

At 2:16 the video states:

Quote

and there is the fact that Chrome started displaying aggressive looking warnings whenever you visited a site without a certificate signed by a recognized authority. Heh, that got HTTPS adoption rolling a bit quicker

I feel like this sentence tries to say "One day, Chrome decided to start displaying warnings for non-HTTPS websites, so that made people switch over to HTTPS quicker". That is not what happened. Chrome doesn't display warnings when visiting HTTP websites.

Chrome has since day 1 displayed warnings when trying to visit websites trying to establish an HTTPS connection without a certificate signed by a recognized authority.

Chrome displaying warnings had nothing to do with the quick adoption of HTTPS. If anything, the potential for warnings in Chrome would have deterred people from adopting it, because with HTTP you never get the warning. With HTTPS, you get a warning if you configure it incorrectly or if it expires. The video even says this right after, so it kind of contradicts itself.

 

What the video should have brought up is the fact that in 2014, Google started ranking HTTPS-enabled websites higher in their search results. That's an actual move from Google that resulted in higher HTTPS adoption. Chrome displaying or not displaying a warning was never a factor because that never changed, and was actually an incentive to not enable HTTPS. It has worked the same in all browsers, not just Chrome, for ages too.

 

Another thing that the video may have gotten confused about and was trying to reference, is that in 2019 Chrome started blocking HTTP subresources from loading on HTTPS websites. But that's not the same as displaying a warning to users saying "ERR_CERT_AUTHORITY_INVALID" like the video shows.

 

 

At 4:10 the video says:

Quote

Another very very important thing to remember is that HTTPS does not encrypt metadata, which includes URLs. This means an attacker, network administrator, or ISP can still determine which sites you are visiting, and in certain circumstances even which specific web pages, depending on how the server is configured.

This is very misleading at best, and flat-out wrong at worst.

It is true that some metadata is not encrypted in some versions of HTTPS. How much and what data is or isn't encrypted depends on a few factors like which browser you use and how the website you're connecting to is configured.  But even if you use a fairly old browser and the website isn't the best-configured privacy-wise, the URL will still mostly be encrypted if you use HTTPS. It is typically only the domain that can be disclosed by sniffing HTTPS traffic, and this is why it is so important to keep the term "URL" separated from the term "domain".

 

Only the fully qualified domain name portion of the traffic is unencrypted in the URL. Pretty much everything else is encrypted. It'a also possible to derive information like the scheme and port used so I guess you could call that encrypted and part of the URL too, but that's a bit more complicated and nuanced. So let's just go with "the domain name is the only unencrypted part". Everything else, the path, anchor, parameters etc, is encrypted. With things like ECH or ESNI, the domain name and SNI can also be encrypted.

 

I will also call bullshit on the part about "in certain circumstances, even which specific web pages [can be sniffed over HTTPS]". I'd like to see a source on that claim because as far as I know, things like the path will always be encrypted in HTTPS. So no, an attacker can't see which specific web page you visit. They can potentially see which domain you are visiting, but not which precise page on that domain. They might be able to see that you visited Amazon, but they won't be able to see which product on Amazon you viewed for example.

 

 

At 4:39 the video says:

Quote

there is some good news here. Encrypted DNS is gaining popularity, which means in laymen terms that the hostname of the pages you are visiting would be encrypted

No, it doesn't It doesn't at all mean that.

Encrypted DNS means that the DNS requests are encrypted. That's it. The DNS requests are a completely separate thing from HTTPS requests to visit a website.

The HTTPS requests made once you have obtained the IP using DNS still disclose the domain name unless you use ECH or ESNI.

 

Even if you use encrypted DNS, once you visit a website like https://linustechtips.com, the ClientHello message, which is part of the HTTPS handshake, still sends the domain name in clear text. Your browser does not care if you obtained the IP using encrypted DNS or not. It behaves exactly the same regardless, and by exactly the same I mean it sends the domain name in clear text unless something like ECH or ESNI is used.

 

 

 

 

 

 

Edit:

Ignore this part, it is true that you get a unique key but it can be figured out if someone is sniffing the traffic when you connect, which is a big risk:

Spoiler

 At 0:25 the video states:

Quote

Without HTTPS any of that content such as private messages, payment info or the videos you're watching could be intercepted by an attacker or Snoop such as someone with a packet sniffing program connected to the same Wi-Fi network [shows image of a coffee shop], or by an IT administrator monitoring traffic at your office.

This is not really true. The likelihood of someone on the same Wi-Fi network being able to sniff your traffic is pretty low these days. Why? Because when you connect to a Wi-Fi network that uses WPA2 or WPA3, your traffic isn't actually encrypted using the pre-shared key that you type in to connect to the network. Instead, the client and access point negotiate a unique session key which is only used for unicast traffic between the client and the access point. This key is called the Pairwise Transient Key (PTK). 

 

To be 100% clear, just because multiple computers connect to the same Wi-Fi network using the same password, does not mean they can listen to traffic from each other. A unique key is created and used for unicast traffic which ensures that things like your private messages can't be snooped on by other clients on the same Wi-Fi network, even if they are sent using HTTP.

 

The traffic is decrypted at the access point though, so it is true that an IT administrator or someone sitting "after" the access point in the traffic chain could see your traffic. I just object to the statement that someone on the same network in like a coffee shop could snoop on you. It is extremely unlikely that they could, unless they somehow manage to break the encryption used by WPA2/WPA3, which so far hasn't really happened.

 

[wanderingfool2]

6 minutes ago, LAwLz said:

This is not really true. The likelihood of someone on the same Wi-Fi network being able to sniff your traffic is pretty low these days. Why? Because when you connect to a Wi-Fi network that uses WPA2 or WPA3, your traffic isn't actually encrypted using the pre-shared key that you type in to connect to the network. Instead, the client and access point negotiate a unique session key which is only used for unicast traffic between the client and the access point. This key is called the Pairwise Transient Key (PTK). 

That completely ignores the use-case of how people would be connecting to Wi-Fi networks though.  It's easy enough to create a Wi-Fi network with the same SSID and then people who are connecting to the network will just join onto it...also there are a crazy amount of networks which don't utilize WPA2 or WPA3 (those local coffee shops) for the guest network

 

It's the whole reason why FireSheep became such a big thing for a while; and why there was a giant push to have everything done on HTTPS

 

16 minutes ago, LAwLz said:

I think it is important to note that it would only be possible for a proxy to decrypt HTTPS traffic if the employer somehow got a root certificate onto the computer you're using to browse the web. This is the case in a lot of corporate environments where the computer is managed by an IT department, but I think it is important to note that it's not like a proxy can magically decrypt traffic transparently if HTTPS is used. The manager of the proxy has to either tamper directly with your device to make it trust the proxy, or it will throw up certificate errors and warn you that your traffic is about to be decrypted.

Some programs are also using what's called certificate pinning, which means that you can not put up a proxy and decrypt the traffic even if the IT administrator puts a root certificate onto your device. One notable example that uses this is Dropbox. You can not do a MITM on a Dropbox client trying to connect to Dropbox's servers. No proxy, firewall, or other thing can decrypt that traffic in transit.

I agree with you on this one; it is possible to do, but it should have been stressed that they would essentially have had to put in a root cert on the computer...and I don't think any normal sized company would even have the IT people to do that.

 

20 minutes ago, LAwLz said:

There are several points in the video where the word "URL" is used when "domain" would have been a better word. This might sound like nitpicking, but this is actually a very important distinction when talking about HTTPS because HTTPS does not encrypt the domain portion of a URL. It does however encrypt parts of the URL like the path, query, fragment, and so on. 

Agree 100% on the 4:10 (didn't bother watching the video but did click on the 4:10 part).  Yea, they should have mentioned doesn't encrypt the domain or subdomain

24 minutes ago, LAwLz said:

I feel like this sentence tries to say "One day, Chrome decided to start displaying warnings for non-HTTPS websites, so that made people switch over to HTTPS quicker". That is not what happened. Chrome doesn't display warnings when visiting HTTP websites.

Chrome has since day 1 displayed warnings when trying to visit websites trying to establish an HTTPS connection without a certificate signed by a recognized authority.

Don't get me wrong, their statement is very wrong; but I think what they might have been getting at is that Google enabled warnings when there was mixed content which that wasn't really a thing that happened.

 

Honestly, I think things like FireSheep though was what spurred on a lot of push towards https everywhere on a site.

 

26 minutes ago, LAwLz said:

This is very misleading at best, and flat-out wrong at worst.

It is true that some metadata is not encrypted in some versions of HTTPS. How much and what data is or isn't encrypted depends on a few factors like which browser you use and how the website you're connecting to is configured.  But even if you use a fairly old browser and the website isn't the best-configured privacy-wise, the URL will still mostly be encrypted if you use HTTPS. It is typically only the domain that can be disclosed by sniffing HTTPS traffic, and this is why it is so important to keep the term "URL" separated from the term "domain".

Agree 100%

[leadeater]

10 hours ago, LAwLz said:

I just object to the statement that someone on the same network in like a coffee shop could snoop on you. It is extremely unlikely that they could, unless they somehow manage to break the encryption used by WPA2/WPA3, which so far hasn't really happened.

That really depends on how the Guest wireless network has been setup in such a scenario. Lots of places for the Guest network specifically don't use any encryption at all, only Captive Portal and 'Client Isolation' but this does not prevent wireless traffic snooping.

 

Quote

No password required! All you need to do is select the Wi-Fi network and enter your name and email to get access.

 https://www.mcdonalds.com/gb/en-gb/help/faq/what-s-the-password-for-using-wi-fi-in-a-mcdonald-s-restaurant.html

https://www.mcdonalds.com/us/en-us/services/free-wi-fi.html

 

This is the most common type of "Free WiFi" any person will encounter and it's done like this to achieve, as best as possible, no technical support requirement and the simplest connectivity possible. McDonalds does not offer any support in restaurant for getting connected.

 

So it's actually extremely likely someone could snoop. If you don't know if encryption is being used on the WiFi connection and it's a Guest/Free WiFi then the most prudent and best advice is to assume it is not encrypted and anyone can snoop the traffic.

 

Non "Guest/Free WiFi" is, almost always, encrypted. Within an at work situation network layer monitoring should be assumed, at a minimum traffic logging at the firewall, but could also be going through a transparent proxy that is logging web traffic and in more rare cases SSL Full Inspection (responsible disclosure should be applied, tell your users).

 

10 hours ago, LAwLz said:

I think it is important to note that it would only be possible for a proxy to decrypt HTTPS traffic if the employer somehow got a root certificate onto the computer you're using to browse the web.

This information was provided, it's just difficult to insert in to a TQ video without that one subject area dominating it over the rest, consider if you keep expanding and adding more detail to each thing the video quickly becomes not a TQ. The other factor is this isn't really all that easily comprehendible to a non IT person in this field. It's one thing to provide this information and another to assume that it's been understood and sufficiently encapsulated in to the script/video.

 

The second go around of this video was not reviewed by ECC, a good amount was changed and I'll assume even reshot going by the T-Shirt change and the very long time between ECC looking at the original and the public release here.

 

10 hours ago, LAwLz said:

Some programs are also using what's called certificate pinning, which means that you can not put up a proxy and decrypt the traffic even if the IT administrator puts a root certificate onto your device. One notable example that uses this is Dropbox. You can not do a MITM on a Dropbox client trying to connect to Dropbox's servers. No proxy, firewall, or other thing can decrypt that traffic in transit.

This is a good point but also in my opinion beyond the scope of this TQ video.

 

10 hours ago, LAwLz said:

1:13 although this might be a bit nitpicky because it is true, but I feel like it was accidentally true and could still be a bit misleading.

This was a correction/addition from the original video. Tip, any "Grey shirt Riley" is new and originated from ECC review and comments (with the note of these not being reviewed) aka the corrections weren't able to be corrected heh.

 

10 hours ago, LAwLz said:

3:50 This is like the mention at 1:13 technically correct, but I feel like it was accidental. The correct terminology would be domain in that cases, even though the URL contains the domain so what is said is in a way true.

4:10 This is where it is very wrong to say URL instead of domain. More on this later.

Same comment as above although from memory much of this was in the original video, just some minor changes here other than 4:04 which has been feed back already that this was not the correct/sufficient way to portray the concept as domain names, DNS and URLs are different subject areas in this context.

 

10 hours ago, LAwLz said:

I feel like this sentence tries to say "One day, Chrome decided to start displaying warnings for non-HTTPS websites, so that made people switch over to HTTPS quicker". That is not what happened. Chrome doesn't display warnings when visiting HTTP websites.

Chrome actually does but not in the way shown in the video, I think just a large amount of confusion/misunderstanding went on here.

https://blog.google/products/chrome/milestone-chrome-security-marking-http-not-secure/

 

This is the warning Chrome gives to any site not using HTTPS, the warning shown in the video is improper HTTPS functionality and Chrome will display similar warning page as shown in the video with details about what specifically is the problem if possible. Overall in large part that type of warning page is reserved only for issues with HTTPS as it's more critical to warn on these.

 

P.S. Sorry time codes I have give up to this point are the FP version, now switching to YT since I see that is your source.

 

10 hours ago, LAwLz said:

This is very misleading at best, and flat-out wrong at worst.

It is true that some metadata is not encrypted in some versions of HTTPS. How much and what data is or isn't encrypted depends on a few factors like which browser you use and how the website you're connecting to is configured.  But even if you use a fairly old browser and the website isn't the best-configured privacy-wise, the URL will still mostly be encrypted if you use HTTPS. It is typically only the domain that can be disclosed by sniffing HTTPS traffic, and this is why it is so important to keep the term "URL" separated from the term "domain".

-snip-

This was addressed during the review however it seems to have been incorrectly addressed and wordage of URL rather than Domain used. SSL Certificate Inspection information was provided as one form of Meta Data possible to be obtained when accessing HTTPS websites, since that and TLS handshake are how this is obtained/can be obtained. But this is only for the Domain being accessed, also URL Re-Writes and transparent redirections that direct traffic to another place behind a Forward Proxy/Load Balancer where SSL Bridging or Offloading may be used complicate that matter further (Beyond the scope of this TQ video).

 

10 hours ago, LAwLz said:

No, it doesn't It doesn't at all mean that.

Encrypted DNS means that the DNS requests are encrypted. That's it. The DNS requests are a completely separate thing from HTTPS requests to visit a website.

The HTTPS requests made once you have obtained the IP using DNS still disclose the domain name unless you use ECH or ESNI.

 

Even if you use encrypted DNS, once you visit a website like https://linustechtips.com, the ClientHello message, which is part of the HTTPS handshake, still sends the domain name in clear text. Your browser does not care if you obtained the IP using encrypted DNS or not. It behaves exactly the same regardless, and by exactly the same I mean it sends the domain name in clear text unless something like ECH or ESNI is used.

This has been feed back since the video release. Some of this was covered during the review however I don't think sufficiently, or at least wasn't understood well enough. I can't see the review comments anymore so going off memory.

 

One thing I asked for that stemmed from the original review of this video was the scripts to be posted for review first, which is just now starting to get done.

 

Wireshark capture of a TLS Handshake I provided to them today:

Spoiler

 

The last thing I'll point out is the objective goal of TQ is short digestible information targeting around 5 minute video run time. Maybe or maybe not you underestimate how difficult that actually is. You can be technically correct on all points and details covering specifics but can you do it in 5 minutes? Mixing up usages of DNS, Domain and URL is certainly fair criticism obviously but do remember to keep this point in mind and what TQ is, aka not to learn about half the details talked about in this topic. Once you start talking about TLS Handshakes, SNI, ESNI, SSL Inspection vs SSL Full Inspection then we're no longer in TQ territory (each of these alone can be talked about for more than 5 minutes, so their own TQ or details omitted).

[leadeater]

4 hours ago, wanderingfool2 said:

also there are a crazy amount of networks which don't utilize WPA2 or WPA3 (those local coffee shops) for the guest network

Basically almost all of them. Needing a pre-shared key/password is a significant problem for Guest networks. The only half decent solution I have seen is unsecured captive portal provides a one time password for the secured Guest network and instructs how to reconnect using this password, everything else is blocked on the unsecured wireless.

[wanderingfool2]

1 hour ago, leadeater said:

Basically almost all of them. Needing a pre-shared key/password is a significant problem for Guest networks. The only half decent solution I have seen is unsecured captive portal provides a one time password for the secured Guest network and instructs how to reconnect using this password, everything else is blocked on the unsecured wireless.

I've come across a decent amount of them that do require a password (then again I sort of ignore public Wi-Fi stuff unless I really need it...and that's usually only when I'm traveling and sitting in my hotel room), but yea a crazy amount don't...but I mean realistically it doesn't mean too much when there is a password given out if everyone else is given the password...as most won't know if you are connecting to the actual Wi-Fi network or one that just has the same SSID (that is control by someone malicious).  If you are malicious enough to try monitoring what is happening; you probably also are capable of just spinning up a spoofed Wi-Fi.  Either way there is still a glaring amount of attack vectors when people are connecting to any old Wi-Fi's.

 

Actually, I could be wrong, but I believe there was an attack that was similar to this from maybe 4 - 5 years ago???  Can't remember the specifics; but it was people who actually targeted corporations by spoofing the SSID with the same password and people's phones would just try connecting to it automatically (like they had set it up at the restaurant across the street).  They used it intercept emails and other business related activities iirc.

 

Also slightly related, I found this interesting to read back when I was more focused on this kind of stuff.

https://www.wired.com/story/tinder-lack-of-encryption-lets-strangers-spy-on-swipes/

 

[ili]

A comment was pined, so this was classified as 2 in the SOP as I understand?

I think this should be classified as 3.

The main question of the video is if HTTPS protect you.

The statement that TLS dose not encrypt the URL and then the resulting statement that the specific page you are visiting can be known is a significant part of the video main premise and conclusion.

[starsmine]

I want to also add that its a big assumption to assume password-protected networks are using WPA2/3

There are many networks with devices of many ages on them. Some of which are old and have no support for WPA2, let alone 3. I know of a few places that use WEP, fully knowing that was fully broken over a decade ago, simply because it lets them use the old device and "it keeps the honest people honest".

I dont know of any networks using WPA3 because that was not required on new devices until 2020, and it was not even an option to put into a device until 2018

[mMontana]

2 minutes ago, starsmine said:

I know of a few places that use WEP, fully knowing that was fully broken over a decade ago, simply because it lets them use the old device and "it keeps the honest people honest".

Sorry

 

 

[LAwLz]

22 hours ago, wanderingfool2 said:

That completely ignores the use-case of how people would be connecting to Wi-Fi networks though.  It's easy enough to create a Wi-Fi network with the same SSID and then people who are connecting to the network will just join onto it...also there are a crazy amount of networks which don't utilize WPA2 or WPA3 (those local coffee shops) for the guest network

That's true. What I said obviously only applies to networks with WPA2. This might be a cultural thing, but here in Sweden pretty much all networks use WPA2, even those in coffee shops. Stores just write the password somewhere and have users put it in. The amount of open networks is extremely low.
Of course, it doesn't protect from someone creating a fake network with the same credentials, but I feel like that's a bit beyond the scope of this. I just feel like there should at least have been an asterisk or further clarification like saying "same open Wi-Fi network" instead of just "same Wi-Fi network". Because the impression I got from this video, and the impression I think a lot of people may reach from the way this is worded, is that if you are on the same Wi-Fi then your traffic can be snooped, which it can't unless further attacks are employed (like spoofing), and in those case the traffic isn't snooped by clients on the same network as the video claims, it would be snooped by the "IT administrator monitoring traffic".

 

Another caveat is that you can actually encrypt traffic on open networks by using Opportunistic Wireless Encryption (OWE), but that's new and I haven't seen that in the wild yet (partially because we don't have many open networks in Sweden).

 

 

22 hours ago, wanderingfool2 said:

Don't get me wrong, their statement is very wrong; but I think what they might have been getting at is that Google enabled warnings when there was mixed content which that wasn't really a thing that happened.

 

Honestly, I think things like FireSheep though was what spurred on a lot of push towards https everywhere on a site.

I am not so sure FireSheep had any impact on how many websites used HTTPS. I think it absolutely had an impact on how much of websites used HTTPS, but I don't think it increased the number of websites that had HTTPS implemented at all. My guess is that it it made websites that had HTTPS implemented for certain things implement it on everything. I don't think websites that didn't have any HTTPS functionality at all suddenly decided to implement it because of FireSheep though.

 

If I had to attribute the increase in HTTPS usage to three things I would attribute it to:

1) Let's Encrypt making certificates free and easy.

2) Google giving HTTPS websites a boost in rankings.

3) Computer performance, especially for things like AES, has gotten way better so the fear that it may slow down websites is gone. Doing HTTPS used to be very taxing on both the servers and the clients.

[LAwLz]

19 hours ago, leadeater said:

That really depends on how the Guest wireless network has been setup in such a scenario. Lots of places for the Guest network specifically don't use any encryption at all, only Captive Portal and 'Client Isolation' but this does not prevent wireless traffic snooping.

Yes, but that's why I think they should have added a few more words to clarify it more. For example instead of just saying "same Wi-Fi network" they should have said "same open Wi-Fi network". It's just one more word and it makes a massive difference.

 

 

19 hours ago, leadeater said:

This is the most common type of "Free WiFi" any person will encounter and it's done like this to achieve, as best as possible, no technical support requirement and the simplest connectivity possible.

I will concede that what they say is true for most open networks, and open networks might be the most common people in some parts of the world may encounter, but I will still argue that adding the word "open" to the sentence would have made a big difference and made the information not just more correct, but also avoid potential misunderstandings.

 

 

19 hours ago, leadeater said:

This information was provided

I must have missed it. Where was that information provided?

 

 

19 hours ago, leadeater said:

it's just difficult to insert in to a TQ video without that one subject area dominating it over the rest, consider if you keep expanding and adding more detail to each thing the video quickly becomes not a TQ. The other factor is this isn't really all that easily comprehendible to a non IT person in this field. It's one thing to provide this information and another to assume that it's been understood and sufficiently encapsulated in to the script/video.

I understand and agree, but to me, if you are making a short and concise video about something then you need to be way more careful with the way things are worded than if you make a longer video where you can afford to clarify things.

It is possible to simplify a subject and ignore certain details, without generalizing to the point where the things you are saying are untrue.

 

For example, "a proxy at work can decrypt your HTTPS traffic" is in many, many cases false.

"A proxy at work may be able to decrypt your HTTPS traffic" is true and not any harder to say or comprehend. It adds much-needed nuance without padding the video with excessive details.

 

 

19 hours ago, leadeater said:

The second go around of this video was not reviewed by ECC, a good amount was changed and I'll assume even reshot going by the T-Shirt change and the very long time between ECC looking at the original and the public release here.

I don't know what ECC is, and I don't really care to know either. I am just commenting on the video as presented to me.

 

 

19 hours ago, leadeater said:

This is a good point but also in my opinion beyond the scope of this TQ video.

Yes, I agree. I wasn't trying to say "they should have included things about certificate pinning in the video". It was just me adding more reasons why they shouldn't have made such an overly generalized statement in the way they did, because it is wrong. It was just me adding more points to disprove their statement.

 

 

19 hours ago, leadeater said:

This was a correction/addition from the original video. Tip, any "Grey shirt Riley" is new and originated from ECC review and comments (with the note of these not being reviewed) aka the corrections weren't able to be corrected heh.

I assume "ECC" is the name for the "let viewers correct us" thing I've seen people mention.

If this is the state of a "corrected" video then I don't want to imagine what the first version looked like, and I am honestly quite disappointed if this is the best they could do even after corrections.

 

In my opinion, this video should be pulled down and reworked from the ground up. The impression I got from this video is that it was made by someone who doesn't really understand HTTPS yet feels like they should explain it to others, and in my opinion explaining things in a quick and concise way is more difficult than doing it in a "long format" video, so it makes the situation even worse.

 

 

19 hours ago, leadeater said:

Chrome actually does but not in the way shown in the video, I think just a large amount of confusion/misunderstanding went on here.

https://blog.google/products/chrome/milestone-chrome-security-marking-http-not-secure/

Oh that's a good point that I forgot about.

If that's what they are referring to then that makes more sense. But it is in my opinion a very bad situation if a video designed for educational purposes is described as "a large amount of confusion/misunderstanding".

It's a pretty massive fuckup and what they show is literally the opposite of what they are talking about in that case.

 

If I, who work with this all the time don't understand what they are talking about, then I can only imagine how confused (possibly without even realizing it) the average viewer must be. 

 

 

 

 

 

19 hours ago, leadeater said:

The last thing I'll point out is the objective goal of TQ is short digestible information targeting around 5 minute video run time. Maybe or maybe not you underestimate how difficult that actually is. You can be technically correct on all points and details covering specifics but can you do it in 5 minutes? Mixing up usages of DNS, Domain and URL is certainly fair criticism obviously but do remember to keep this point in mind and what TQ is, aka not to learn about half the details talked about in this topic. Once you start talking about TLS Handshakes, SNI, ESNI, SSL Inspection vs SSL Full Inspection then we're no longer in TQ territory (each of these alone can be talked about for more than 5 minutes, so their own TQ or details omitted).

I understand how difficult that is, which is why I think it is a very bad idea to have people who don't know much about the subject try and do it.

It just ends up being the blind leading the blind. Trying to do it in a ~5-minute time limit is just turning on hardcore mode.

 

I don't think "they tried to explain it in a short time" is an excuse for making a bad video.

I don't know how to juggle. It would be a very bad idea for me to try and teach others how to juggle. It would be an even worse idea to try and teach juggling while blindfolded. I can't say "hey man, I was blindfolded so cut me some slack" when my attempt fails horribly and someone calls me out on it. It was my idea to try and do it blindfolded to begin with, so that falls on me.

 

TechQuickie needs to learn how to walk before they try to run.

[LAwLz]

18 hours ago, leadeater said:

Basically almost all of them. Needing a pre-shared key/password is a significant problem for Guest networks. The only half decent solution I have seen is unsecured captive portal provides a one time password for the secured Guest network and instructs how to reconnect using this password, everything else is blocked on the unsecured wireless.

As I've mentioned quite a bit, in Sweden it is common for public Wi-Fi's to be WPA2 protected, and then they have the password written somewhere. In  hotels it's written on the greeting card along with the card keys. In schools it's written on the whiteboards. At restaurants, it's written on the big display menu or at the tables. At events and things like museums, it's written on the ticket.

 

As time goes by my guess (and hope) is that OWE will be deployed on open Wi-Fi networks.

 

 

 

  

6 hours ago, starsmine said:

I want to also add that its a big assumption to assume password-protected networks are using WPA2/3

There are many networks with devices of many ages on them. Some of which are old and have no support for WPA2, let alone 3. I know of a few places that use WEP, fully knowing that was fully broken over a decade ago, simply because it lets them use the old device and "it keeps the honest people honest".

I dont know of any networks using WPA3 because that was not required on new devices until 2020, and it was not even an option to put into a device until 2018

I don't think this is a real issue. WEP was deprecated 19 years ago, and it was discovered to be completely unsafe 23 years ago. It wasn't fully broken just "a decade ago", it was fully broken several decades ago.

Unless you're running around with a 15 year+ old Wi-Fi device, your device supports WPA2, and personally, I have pretty much never seen a WEP network in the last 5 years. Of course there are some that still use it, but if we're going to talk about real-world dangers in a short ~5 minute video then I don't think it's worth bringing up WEP since less than 1% of networks use that. WPA2 is the current de-facto standard.

 

I haven't been able to find that much reliable information, but this website tracks Wi-Fi statistics.

This website says WEP accounts for 3.40% of all networks. However, one issue with this website is that it doesn't age out data.

 

If we instead look at only data collected in the last 2 years, the statistics look like this:

WEP - 0.90%

WPA - 0.86%

WPA2 - 81.74%

 

It also shows that the amount of unencrypted networks is 0.98%, with 85.07% of networks being encrypted, and the remaining 13.95% being "unknown" (probably a mix).

 

 

Anyway, I think we are getting too much into the weed of things and I'd like for the conversation to focus on the very big and glaring issues in the video.

[wanderingfool2]

On 9/9/2023 at 2:43 PM, LAwLz said:

I am not so sure FireSheep had any impact on how many websites used HTTPS. I think it absolutely had an impact on how much of websites used HTTPS, but I don't think it increased the number of websites that had HTTPS implemented at all. My guess is that it it made websites that had HTTPS implemented for certain things implement it on everything. I don't think websites that didn't have any HTTPS functionality at all suddenly decided to implement it because of FireSheep though.

It was the news surrounding it (in non-tech news outlets), that helped drive the browser makers start putting in warnings about the mixed content; and at the same time warnings in regards to inputs being sent without any security.

 

On 9/9/2023 at 2:43 PM, LAwLz said:

That's true. What I said obviously only applies to networks with WPA2. This might be a cultural thing, but here in Sweden pretty much all networks use WPA2, even those in coffee shops. Stores just write the password somewhere and have users put it in. The amount of open networks is extremely low.
Of course, it doesn't protect from someone creating a fake network with the same credentials, but I feel like that's a bit beyond the scope of this. I just feel like there should at least have been an asterisk or further clarification like saying "same open Wi-Fi network" instead of just "same Wi-Fi network". Because the impression I got from this video, and the impression I think a lot of people may reach from the way this is worded, is that if you are on the same Wi-Fi then your traffic can be snooped, which it can't unless further attacks are employed (like spoofing), and in those case the traffic isn't snooped by clients on the same network as the video claims, it would be snooped by the "IT administrator monitoring traffic".

Connecting to spoofed wifi isn't out of the scope...it's a literal vector of attack anyone could use and it does get used.  People creating fake hotspots is very much a thing.

 

Also can we stop with this whole WPA2 nonsense that you can't decrypt the traffic.  WPA2 DOESN'T prevent easedropping.  Your whole talk of PTK and somehow acting like that it protects the communication just shows a lack of understanding in how it works.

 

The PTK between a client and AP can be reconstructed if you were able to capture the 4 way handshake...now the PTK does benefit from the fact that anyone capturing the packets would have to have initially caught the communication but it doesn't strictly prevent someone who has been there all along capturing all packets from doing so.

 

What the PTK does do is prevents the PMK from having to be used and exposed in communication.  So any offline attacks to crack the PMK would be impossible by someone just observing the traffic. (Aside from the handshake)

 

Specifically, the PTK is derived from EAPOL which means again you only have to sniff the packets making WPA2 at a coffee shop being almost as vulnerable as none at all.

 

If you don't believe me, here

https://mrncciew.com/2014/08/16/decrypt-wpa2-psk-using-wireshark/

 

As long as the password is known, you can decrypt the nonce's that the AP and client; and reconstruct the PTK that was made.

 

You I think are missing the general sentiment that when you connect to random Wi-Fi networks or even share a Wi-Fi network with multiple people it's not something that should be trusted.

[leadeater]

1 hour ago, wanderingfool2 said:

Connecting to spoofed wifi isn't out of the scope...it's a literal vector of attack anyone could use and it does get used.  People creating fake hotspots is very much a thing.

 

Also can we stop with this whole WPA2 nonsense that you can't decrypt the traffic.  WPA2 DOESN'T prevent easedropping.  Your whole talk of PTK and somehow acting like that it protects the communication just shows a lack of understanding in how it works

If the wireless password is put on display for all to see then there is no security or protection from bad actors, the password in this scenario is security theatre. I won't repeat what you have said but it's functionally equivalent to an open network, with exception of stopping snooping by the most unsophisticated malicious person aka not all the useful. 

 

Fortunately WPA3 actually has a way to address this, it's just not that wide spread on the wireless infrastructure side or client side yet.

 

Quote

Wi-Fi Enhanced Open (OWE)
Wi-Fi Enhanced Open (OWE) is the open security type derived from WPA3. It runs concurrently with an equivalent legacy Open SSID. Essentially, 2 similar SSIDs are broadcast and OWE capable clients will connect to the OWE version of the SSID, while non-OWE clients will connect to the legacy version of the SSID. Enhanced open provides improved data encryption in open Wi-Fi networks and protects data from sniffing.

https://www.arubainstanton.com/techdocs/en/content/networks/desktop/guest-nwk-des.htm

 

This is the way to do it, if you can. The only issue is it's still open unencrypted for legacy clients. I haven't done any wireless deployment work for a while now so wasn't aware of OWE, seems like solution to the "Free WiFi" problem that has been around for so long. Where possible in the past I had always gone the path of Guest one time passwords and given office staff access to the user management portal to creating these on the Aruba controller (RBAC role for this).

 

You can probably guess, I really like Aruba wireless solutions. Also the above seems to be a 2019 standard so should be hitting wider support in the next 1-3 years, equipment lifecycle.

 

When it comes to independent coffee shops that use WPA2 they are also using consumer home router anyone else would be using and just changed the default password. Large chain restaurant or ones inside a shopping mall use bigger managed infrastructure and are of the open type with the captive portal. I've seen both but the open with captive portal is by far the most common and most likely to be encountered type unless you most often visit small/local coffee shops rather than going to large shopping malls or doing travel (airports, train stations, bus stations etc). I think lifestyle is quite a big factor.

[leadeater]

On 9/10/2023 at 10:50 AM, LAwLz said:

As I've mentioned quite a bit, in Sweden it is common for public Wi-Fi's to be WPA2 protected, and then they have the password written somewhere. In  hotels it's written on the greeting card along with the card keys. In schools it's written on the whiteboards. At restaurants, it's written on the big display menu or at the tables. At events and things like museums, it's written on the ticket.

I hope you are VERY aware that for WPA2 this makes it no better than open. If you are up to play with wireless and security then there isn't much point discussing this. It only stops those that were never a threat to begin with while those you are at risk from you are still at risk from.

 

Hotels I have stayed in all use one time per room passwords, no sharing. Schools don't use "Guest WiFi" for anyone other than actual guests and unless the school is very small have at least a Ruckus wireless solution as every school in my country has funded wired and wireless networks and the wireless is either Ruckus or Aruba depending on school size.

 

As for restaurants they fit in to two categories, small independent and use consumer router, or in some larger setting with managed wireless solution and use captive portal. Lifestyle would dictate what you visit/encounter more for this.

 

As per my McDonalds example, that unfortunately is/has been the gold standard for public free WiFi. This actually is how it's done globally, it's also why OWE needed to be created.

[leadeater]

On 9/10/2023 at 10:30 AM, LAwLz said:

I assume "ECC" is the name for the "let viewers correct us" thing I've seen people mention.

You don't have to assume, it's literally posted here in the forum official section and in at least one of the "what we are going to do" videos LMG put out. You'd have to be quite unaware of a a lot of things to not know about it, but I know you don't really watch much of LTT so I'm not surprised. However I have to say you make a lot of effort to find faults with LTT while still managing to be unaware of things like this 

 

On 9/10/2023 at 10:30 AM, LAwLz said:

I must have missed it. Where was that information provided?

I meant provided to them, not you/viewers etc. 

 

On 9/10/2023 at 10:30 AM, LAwLz said:

I don't know what ECC is, and I don't really care to know either. I am just commenting on the video as presented to me.

Well you should since if you are going to make any statements like "I don't think this was well researched" etc then it reflects negatively on you to be both unaware and also not care about it. I can only go off memory but at least from the point of getting ECC review to public release that was like 2 weeks. Any research before that done to create the original video I don't know but decent amount of effort was put in by LMG to this, it's just unfortunate they did not get their changes reviewed before release. Obviously they have learnt from that.

 

You either be aware and make comments based on understanding and knowledge, or understand and/or accept that you are commenting in ignorance which I personally I don't think is a good place to be in given you want to hold people to standards. But to be clear this doesn't matter unless you make those types of comments or connotations. Criticizing errors in a video is one thing, criticizing the effort put in to it is another and that here would be your error and misinformation.

 

On 9/10/2023 at 10:30 AM, LAwLz said:

If this is the state of a "corrected" video then I don't want to imagine what the first version looked like, and I am honestly quite disappointed if this is the best they could do even after corrections.

It's actually not that bad. I think some of the feedback and comments during the review unfortunately caused some harm rather than helping and created new problems. Some minor things that were picked up and explained in detail around them created some of the above problems because that information either wasn't well understood or wasn't clear what did and did not need to go in to the video.

 

It's one of my concerns over the ECC program, needless nit picking that doesn't take in to account target audience or video purpose that end up creating more harm than good. Some generalizations don't actually matter even if there are exceptions or situations that change it away from the generalization, this is what a generalization actually is.

[LAwLz]

5 hours ago, wanderingfool2 said:

Connecting to spoofed wifi isn't out of the scope...it's a literal vector of attack anyone could use and it does get used.  People creating fake hotspots is very much a thing.

It's out of the scope of a video talking about HTTPS security. Likewise, talking about potential trojans that may be on your computer and thus being able to spy on your browser data is also out of the scope. It's a security threat for sure, but a very different one from what the video talks about. It would also fall under the "IT administrator monitoring the network", so it's kind of already covered.

 

 

My point was that they should have said "may be able to snoop", because it doesn't add complexity to the video and makes it more correct.

 

 

6 hours ago, wanderingfool2 said:

Also can we stop with this whole WPA2 nonsense that you can't decrypt the traffic.  WPA2 DOESN'T prevent easedropping.  Your whole talk of PTK and somehow acting like that it protects the communication just shows a lack of understanding in how it works.

But, it does...

 

 

6 hours ago, wanderingfool2 said:

The PTK between a client and AP can be reconstructed if you were able to capture the 4 way handshake...now the PTK does benefit from the fact that anyone capturing the packets would have to have initially caught the communication but it doesn't strictly prevent someone who has been there all along capturing all packets from doing so.

That's a pretty big IF.

It's for sure not a silver bullet, but it's A LOT more secure than an open network.

Security isn't always about finding a perfect solution with zero flaws. A lot of times it's about putting up roadblocks that hopefully prevent some attacks.

 

 

 

 

 

6 hours ago, wanderingfool2 said:

You I think are missing the general sentiment that when you connect to random Wi-Fi networks or even share a Wi-Fi network with multiple people it's not something that should be trusted.

Fair enough.

I also overestimated the security of the unique WPA2 key, but I still think they could have worded things better, and also believe my other points still stand.

[Kisai]

5 hours ago, leadeater said:

 

It's one of my concerns over the ECC program, needless nit picking that doesn't take in to account target audience or video purpose that end up creating more harm than good. Some generalizations don't actually matter even if there are exceptions or situations that change it away from the generalization, this is what a generalization actually is.

Pretty much.

 

All that matters is the established information is correct, or correct-enough for someone to understand without needing to google all the jargon.

 

Like I'm someone who really really HATES how this all rolled out, as it's instituted a series of code-rot and server-rot that is unsolvable (for example Adobe update servers for CS software will only connect if you set the time of YOUR PC to 2009) , and the really asshat-nature of Google and Firefox choosing not to support HTTP/2.0 fully. Thus, no point in enabling 2.0 on servers, and any "potential" security benefit of 2.0 is lost by still sending some of the connection information unencrypted.

 

I jumped through so many bloody hurdles to get 2.0 to work but SSL TLS 1.3 changes keeps upsetting it, and I'm really wondering if anyone actually cares about SSL unless they're a bank, because the onerous requirements for pretty much any other site seems to add negative value to the site in maintenance expense, and results in making old devices and software unable to connect:

 

Below is one site where I have TLS 1.2 and TLS 1.3 enabled with CBC still available, note all http 1.1:

 

And this is a site that is using the same configuration without CBC, where http 2.0 is available:

 

"This site works only in browsers with SNI support."

 

The only way to get A+ is to enable HSTS and good god is that ever a pain to fix websites when it's enabled. You better make damn sure that your redirects are all correct, because if they aren't, your visitors will be visiting broken pages until they delete their browser cache.

 

 

 

[LAwLz]

6 hours ago, leadeater said:

If the wireless password is put on display for all to see then there is no security or protection from bad actors, the password in this scenario is security theatre. I won't repeat what you have said but it's functionally equivalent to an open network, with exception of stopping snooping by the most unsophisticated malicious person aka not all the useful.

No, it's not "security theater", and it is not "functionally equivalent to an open network".

Open networks sends everything unencrypted. A WPA2 network with a PSK sends everything encrypted, but in some cases it is possible for an attacker to derive the key (or set up a fake hot spot).

Just because there are two potential attack vectors does not mean it is equivalent to having literally zero security at all. Some security is still better than none.

 

 

 

6 hours ago, leadeater said:

You don't have to assume, it's literally posted here in the forum official section and in at least one of the "what we are going to do" videos LMG put out. You'd have to be quite unaware of a a lot of things to not know about it, but I know you don't really watch much of LTT so I'm not surprised. However I have to say you make a lot of effort to find faults with LTT while still managing to be unaware of things like this 

I haven't really followed the who "scandal" or the follow up because I don't really care.

I just saw the video in the sidebar and I have heard from others that they will strive to make more accurate videos, which is something I have been telling them for years. So I thought I'd check out the video since it was about a subject I like and suspected LTT would get things wrong on.

I don't make much effort at all. It's just a ~5 minute video and the issues were very big and glaring. I don't care or follow the whole process of them making videos, I just comment on the things presented to me. I would have to put in a lot more effort if I did follow all the "behind the scenes" stuff.

 

 

 

6 hours ago, leadeater said:

Well you should since if you are going to make any statements like "I don't think this was well researched" etc then it reflects negatively on you to be both unaware and also not care about it. I can only go off memory but at least from the point of getting ECC review to public release that was like 2 weeks. Any research before that done to create the original video I don't know but decent amount of effort was put in by LMG to this, it's just unfortunate they did not get their changes reviewed before release. Obviously they have learnt from that.

I watched the video and commented on the contents of it, that's it. If you go back and reread my posts, you will find that I never said the things you are quoting like "I don't think this was well researched". What I said was that I am quite disappointed if this is the best they could do after corrections, because the video still needs a lot of corrections. I also said that I get the impression that the video was made by someone who doesn't really understand HTTPS, and that I don't think they should make videos trying to teach others in that situation. They need to understand the subject first before trying to teach others. 

 

 

I feel like you are acting quite hostile toward me and don't see why you felt the need to include comments like:

6 hours ago, leadeater said:

You either be aware and make comments based on understanding and knowledge, or understand and/or accept that you are commenting in ignorance which I personally I don't think is a good place to be in given you want to hold people to standards. But to be clear this doesn't matter unless you make those types of comments or connotations. Criticizing errors in a video is one thing, criticizing the effort put in to it is another and that here would be your error and misinformation.

That to me just comes across as "oh no, they pointed out mistakes in the video so now I must point out mistakes from them to try and defend LTT". Maybe that's not your intention, but that's how it comes across to me since you are making direct comments about me as a response to me commenting on a video and its content.

 

I am not sure where you got the idea from that I said they don't put in effort when making these videos. I never said they didn't. But what I will say is that to me, it doesn't matter how much effort someone puts into something. The only thing that matters to me as a viewer is the end result. A bad video is a bad video regardless if someone spent 10 minutes making it, or 10 hours. 

 

 

 

6 hours ago, leadeater said:

It's actually not that bad. I think some of the feedback and comments during the review unfortunately caused some harm rather than helping and created new problems. Some minor things that were picked up and explained in detail around them created some of the above problems because that information either wasn't well understood or wasn't clear what did and did not need to go in to the video.

 

It's one of my concerns over the ECC program, needless nit picking that doesn't take in to account target audience or video purpose that end up creating more harm than good. Some generalizations don't actually matter even if there are exceptions or situations that change it away from the generalization, this is what a generalization actually is.

I think we'll just have to agree to disagree on that one (the video needing to be reworked and replaced).

I think some of the things said in the video are big enough errors to mislead the audience and arrive at a very wrong conclusion, and I don't think a comment below the video is enough, especially not after the initial rush of views, and not on a video specifically aimed at people who just want quick and concise information. I sadly don't think the main target audience for this type of video will scroll down to the comments and read the explanation of how some of the things they just learned are incorrect, and I especially don't think that audience will revisit the video after already having watched it to see if a correction was made.

 

The info needs to be correct from the get-go, at the very least on the TechQuickie channel.

I also don't think it is a good idea for them to make TechQuickie videos about subjects it appears they don't understand very well. As I said earlier, making a quick and concise informative video is more difficult than making a long video, so you really need to have a very good understanding of the subject to make one. The fact that they misunderstood information provided by their fact checker indicates to me that maybe they shouldn't have made a video about this to begin with. Again, they need to learn to walk (understand how HTTPS works) before they try to run (make educational videos that are very time-pressured).

[maplepants]

On 9/9/2023 at 1:15 AM, wanderingfool2 said:

I agree with you on this one; it is possible to do, but it should have been stressed that they would essentially have had to put in a root cert on the computer...and I don't think any normal sized company would even have the IT people to do that.

Maybe it's just the countries I've worked, but they always have their own CA installed on all the machines they control and use it to sign the certs for all intranet sites. But even in places where the intranet services had normal DigiCert / LetsEncrypt certs for intranet sites it was very common that DNS had to be resolved via the proxy.

 

So even when the company can't MITM you, the video is right that they can often see the sites you visit.

[leadeater]

2 hours ago, LAwLz said:

No, it's not "security theater", and it is not "functionally equivalent to an open network".

Open networks sends everything unencrypted. A WPA2 network with a PSK sends everything encrypted, but in some cases it is possible for an attacker to derive the key (or set up a fake hot spot).

Just because there are two potential attack vectors does not mean it is equivalent to having literally zero security at all. Some security is still better than none.

Correct it's not EXACTLY the same but it is FUNCTIONALLY the same. A WPA2 password on display for all to see invalidates the security of the wireless network. You could argue "but you give it to people you know and trust all the time" for example at home, schools etc but these are termed as 'trusted users' not 'untrusted' which is what guests are and also malicious actors.

 

Anyone with the knowhow can easily sit in any location with the known password and capture all the traffic they like and they WILL be able to decrypted traffic. Everyone? Maybe not, depends on when you go there and other factors but traffic will be able to be decrypted and that is a 100% guarantee (assuming greater than one person joining/unjoining the network).

 

This is why it IS security theatre, it's making you feel safe when it is NOT. That is why we only give wireless network passwords to trusted users. Any networks with a publicly known password are treated as untrusted and assume compromised and I do not see you disagreeing with this statement. The only difference is you feel that a public WPA2 password for all to see is adding sufficient level of security against malicious actors where I happen to think differently. Personally I'm not concerned with people that weren't going to be able to do anything with an open network in the first place even if they knew how to capture some traffic. Since I treat both network types the same I am therefore safe from both situations.

 

2 hours ago, LAwLz said:

Some security is still better than none.

Wrong, false security is far worse than none. If you are lying or portraying security falsely then you are worse than none. You literally give people false sense of security which changes behavior. It is either secure or it's not, public on display WPA2 passwords are not secure. With a known practical and easy implemented exploit for WPA2 if you know the password I have no idea why you would entertain the idea of disagreeing with this. You are either security minded and foremost or you are not.

 

This isn't some theoretical maybe or some hard to achieve thing, it's fairly straight forward to do it and absolutely achievable.

 

And both these points are only talking about exploiting WPA2 itself and not the more simple just setup a stronger AP with the same SSID and password attack. And if I were to do such a thing I would just look at the broadcasted channels, drown them out with noise and have mine on a clear and generally supported channel increasing the likelihood people would end up connecting to mine.

 

2 hours ago, LAwLz said:

I don't care or follow the whole process of them making videos, I just comment on the things presented to me. I would have to put in a lot more effort if I did follow all the "behind the scenes" stuff.

Then maybe stay away from accusations of not putting in effort if you have no idea. I think you have put zero effort in to the issues of public WPA2 free WiFi networks and you have no idea what you are talking about.

 

See the problem here? Just because I disagree with your opinion of something or inability to explain it well, or otherwise is it fair for me to attack your effort and existing understanding of a subject? I don't really know how much knowledge, experience, research or effort you have put in to this subject area so I would usually stay away from accusations of not putting the effort in. If it's clear someone really doesn't understand something I will tell them so, but I wouldn't typically say they haven't tried and unless they say they haven't or won't read provided information during the course of the discussion. 

 

Anyway it's usually poor form to say someone has not put the effort in when you don't know, they could have put a significant amount in and just not been able to achieve. It's rather discouraging for those that do put the effort in but weren't able to achieve, it does not invite trying again and improving.

 

2 hours ago, LAwLz said:

I feel like you are acting quite hostile toward me and don't see why you felt the need to include comments like

I'm not it's just that I know of no other better word to use in this situation than ignorance because you literally are commenting as such. I know the word has strong negative reception to it but tell me of a more accurate word to use when you have directly said you haven't bothered to look in to any of this and do not care to? Is there something more fitting that you'd find less insulting or hostile? Personally I think it is the most accurate word here, whether or not it was the nicest one to use.

 

2 hours ago, LAwLz said:

A bad video is a bad video regardless if someone spent 10 minutes making it, or 10 hours. 

Correct, my above critiques still apply.

[leadeater]

1 hour ago, LAwLz said:

I think we'll just have to agree to disagree on that one (the video needing to be reworked and replaced).

What you are replying to and your comment was about the original video. I am saying it wasn't that bad, it was in some ways made worse as part of the review while other parts made better. It's not a universal case of the entire video was improved because it was community reviewed.

 

Again you are surmising and stating that a piece of work you have not seen must have been so horrible because of a few things in a video you did get to see you did not agree with. It's probably better to comment on what you have seen rather than what you have not.

[LAwLz]

35 minutes ago, leadeater said:

Then maybe stay away from accusations of not putting in effort if you have no idea.

Holy crap dude, calm down. I never did that. You're attacking a strawman right now.

 

 

35 minutes ago, leadeater said:

Anyway it's usually poor form to say someone has not put the effort in when you don't know, they could have put a significant amount in and just not been able to achieve. It's rather discouraging for those that do put the effort in but weren't able to achieve, it does not invite trying again and improving.

Good thing I never said or did any of those things then, right?

In fact, what I did was exactly what you said I didn't do. I did invite them to try again so they can improve. That's why I said they should redo the video.

 

I am not going to respond to you unless you stop putting words in my mouth and attacking those. Respond to the claims I made regarding the video instead of made-up things to try and paint me as a bad person.

Also, I get the impression that you are very angry at me and I really don't understand why. It's not you I am criticizing, it's a video, and that's why I feel like it's so weird that you as an outside come in and try and attack me.

[FluorescentGreen5]

Reckon we can the attention of an LMG insider in this thread, especially given how there's no official discussion thread for the video in question? Would also like to see the video replaced given how big their pinned comment is.

[Sauron]

I mostly agree, I guess the very first criticism really depends on how that starbucks' wifi is configured so there's the benefit of the doubt on what they actually meant.

[leadeater]

1 hour ago, FluorescentGreen5 said:

Reckon we can the attention of an LMG insider in this thread, especially given how there's no official discussion thread for the video in question? Would also like to see the video replaced given how big their pinned comment is.

Is there not one in the LTT Releases section? Had a quick look and can't find one either. Maybe that's normal for TQ? I usually don't go over to the LTT Releases section of the forum but I don't see other TQ videos there either from what I could tell.

 

Not sure if it's planned to be replaced or not, not something that's going to happen in a matter of days. Although the video itself could be pulled quickly. It's has been weekend there and only coming out of it so nothing was really going to happen over the last 2 days. I know of nothing so far but I'm not really in the know either.

 

I have neither made any suggestions over taking the video down, re-editing it or go through another recording session. I feel that is something LMG needs to come to a decision on themselves without me weighing in on the matter unless asked. Only thing I have been asked is if some of the issues pointed out after the video release are correct or not which I have done.

 

1 hour ago, LAwLz said:

Good thing I never said or did any of those things then, right?

 

On 9/10/2023 at 10:30 AM, LAwLz said:

I don't know how to juggle. It would be a very bad idea for me to try and teach others how to juggle. It would be an even worse idea to try and teach juggling while blindfolded. I can't say "hey man, I was blindfolded so cut me some slack" when my attempt fails horribly and someone calls me out on it. It was my idea to try and do it blindfolded to begin with, so that falls on me.

 

On 9/10/2023 at 10:30 AM, LAwLz said:

which is why I think it is a very bad idea to have people who don't know much about the subject try and do it.

All I can do is show you, there are more after these but this is sufficient enough. Below included since that specifically needs addressing.

 

What I said and what you are responding to and taking offence to is literally how I have taken your comments, it's literally how it sounds and comes off. I'm just not beating around the bush and pretending that's not how it is. You have and are attacking the credibility and the effort undertaken of the video not just the factual correctness of it.

 

On 9/9/2023 at 10:42 AM, LAwLz said:

I will also call bullshit on the part about "in certain circumstances, even which specific web pages [can be sniffed over HTTPS]". I'd like to see a source on that claim because as far as I know, things like the path will always be encrypted in HTTPS.

As someone who has seen the feedback given to the LMG TQ team and saw SSL Full Inspection information provided to them by multiple different people I know for a fact, 100%, that is is NOT BS and they were linked multiple sources of information from multiple different firewall vendors on SSL Full Inspection which is the source of this statement in the video.

 

I myself was one of them but at least 2 other did as well and I was not the first to do so.

 

And no again I'm not angry at you, if you want to be offended that is a choice you can make at this time. My pointing at your delivery and the way you are presenting critique stands, you have not solely addressed the facts and you have denigrated the actual people working on the video. Maybe you cannot see it but that is what I am seeing. Thing is whenever you do it I know you often tend to be oblivious, not maliciously, of this being the case.

 

If it sounds like I have been making you sound like a bad person maybe because that actually is how some of your comments come off and that is not me saying that is how you intend them to be, that's just how they are to others not being you. You cannot control how someone receives or perceives something, what you can do is listen to those concerns rather than just deny them.

 

The TL;DR is and has been dial back and work on the delivery and inflammatory things like "I call BS". It really doesn't help your case at all with the whole "don't know and don't care" situation either.