Light

Episode #814 Quiz

PwnIt and OwnIt
Date: 2021-04-13 | Length: 1.75 hrs | Episode page at twit.tv

About this episode

Chrome and Firefox are blocking browser access to abuse-prone remote ports, including 10080, to thwart NAT Slipstreaming and unsolicited LAN traversal. Google’s FLoC uses weekly browsing history plus SimHash to assign cohort IDs, while EFF offers an opt-out test and site owners can send Permissions-Policy: interest-cohort=().

Your name and email are stored only in your browser local storage for convenience. They are not retained server-side.

NameEmail

Question 1: According to the episode, why did Chrome plan to add TCP port 10080 to its blocked-port list, even though the port is used by some legitimate software?

Question 1

According to the episode, why did Chrome plan to add TCP port 10080 to its blocked-port list, even though the port is used by some legitimate software?

Because it is reserved for root-only system services on Unix and cannot be safely used by normal applications Because it is a standard HTTPS port that browsers are trying to retire in favor of port 443 Because Chrome was removing all support for HTTP and would no longer allow any plain-text web access on alternate ports Because it can be abused in NAT Slipstreaming-style attacks that rely on browser-initiated traffic to specific remote ports

Question 2: What did the EFF's "Am I FLoCed" page determine about Chrome users during the origin trial?

Question 2

What did the EFF's "Am I FLoCed" page determine about Chrome users during the origin trial?

Whether a given Chrome instance had been included in Google's FLoC origin trial Whether a site had opted out of FLoC by sending the Permissions-Policy header Whether a Chrome installation had the Enterprise policy override enabled for blocked ports Whether a browser had third-party cookies fully disabled by default

Question 3: What was the legacy HTTPS back channel in the PHP incident that bypassed gitolite entirely?

Question 3

What was the legacy HTTPS back channel in the PHP incident that bypassed gitolite entirely?

A webdav upload service protected only by mutual TLS client certificates git-http-backend behind Apache2 Digest authentication against the master.php.net user database An unauthenticated rsync endpoint exposed for source-code mirroring gitolite over SSH using public key authentication and repository-side hooks

Question 4: What immediate remediation did the PHP team make regarding passwords after the git.php.net incident?

Question 4

What immediate remediation did the PHP team make regarding passwords after the git.php.net incident?

They kept the old MD5 hashes but added a one-time login token system They reused the prior password database after salting it with TLS session secrets They reset existing passwords and moved new password storage to bcrypt They disabled all password-based access and required SSH keys for every account

Question 5: Which specific flaw and outcome did Kaspersky describe in the later ransomware attacks against unpatched FortiGate SSL VPN devices?

Question 5

Which specific flaw and outcome did Kaspersky describe in the later ransomware attacks against unpatched FortiGate SSL VPN devices?

A stack overflow in the web portal that leaked only hashed passwords from memory A directory-traversal flaw that exposed sslvpn_websession with usernames and plaintext passwords A cross-site scripting flaw that let attackers steal browser cookies from the VPN portal A certificate-validation flaw that let attackers impersonate VPN clients without touching files

Cancel

My Data//Security & Privacy//Clear Local Data

© 2026 Ken ArmstrongSecurity Now™ is a trademark of TWiT LLC. All trademarks and copyrights of the Security Now podcast are respected and reserved to their respective holders.
This is a hobby project made with love and admiration for what Steve Gibson and Leo Laporte have built over 20 years.