41–50 of 126 posts
No one should be installing native apps for this now that we have WebRTC.
To be frank, if Zoom was a web only app (or maybe web plus web-in-a-electron like eg Slack and WhatsApp) there'd be a vocal HN crowd complaining that there was no proper native app.
Earlier quoted context omitted.
Last I checked you didn’t have to install anything. I’m not sure about more advanced usage like screen sharing or how many timing options their are, but for generic “see me, see you” it works fine in the browser.
It does have a web app, but they make it incredibly hard to find. I’m not surprised that some don’t even know about it
This is what I was looking for. Fundamental bug was an overflow of statically-allocated buffer leading to heap corruption.
We gotta get off memory-unsafe languages.
Earlier quoted context omitted.
It does have a web app, but they make it incredibly hard to find. I’m not surprised that some don’t even know about it
Indeed, IIRC, you need to click “download”, reject the download, and then an “ Open in your browser ” dialog appears.
Android app works.
Earlier quoted context omitted.
With DNS one can avoid having to use the firewall for redirection sslsplit documentation actually suggests DNS as an alternative to using firewall Theres a number of easy-to-use UNIX firewalls. Not sure about Windows Proxies allow easy inspection of HTTP traffic, among other things. Arguably sslsplit is itself a proxy, specifically a forward proxy There are many ways to monitor HTTP traffic. More than one way to do i…
Certificate pinning makes it impossible to examine what the software on my own machine is sending over my network! Please don't do that.
Earlier quoted context omitted.
i run the snap Zoom on Ubuntu
Is that more secure? Snaps seem to be shit for performance, so I avoid them by default, but maybe I should be favouring them when I have security concerns.
Earlier quoted context omitted.
Certificate pinning makes it impossible to examine what the software on my own machine is sending over my network! Please don't do that.
Isn't certificate pinning what keeps my employer from MITM'ing my personal email session on their network?
Earlier quoted context omitted.
Certificate pinning makes it impossible to examine what the software on my own machine is sending over my network! Please don't do that.
Isn't certificate pinning what keeps my employer from MITM'ing my personal email session on their network?
Certificate pinning is what protects the main sites (who use pinning) from an advanced attacker or a rogue government who are able get a proper CA to issue fake certificates.
Earlier quoted context omitted.
Certificate pinning makes it impossible to examine what the software on my own machine is sending over my network! Please don't do that.
Isn't certificate pinning what keeps my employer from MITM'ing my personal email session on their network?
As an employee I prefer not to use the corporate network for truly personal email.
If I am the employer that responsibly monitors the traffic to and from our network, including TLS traffic, an employee that uses our network for personal use with a surveillance "tech" company service such as Google Mail, Facebook, etc. is putting her own privacy at risk. Because I can extract her cookies from the traffic, all she has to do is forget to log out once and I now have a "bearer token", i.e., a cookie, with no expiration,^1 that lets me access her account at any time in the future.
1 The type of cookie that lets users stay "logged in" indefinitely. A non-"tech" company with sufficient legitimate sources of revenue besides online ads may not use such cookies. For example, if an employee logs in to her personal bank account using the corporate network but forgets to log out, the bank website will log her out automatically, the cookies will expire.
Earlier quoted context omitted.
The HTTP and XMPP traffic is encrypted using TLS. The proxies were used to decrypt, log and re-encrypt this traffic in real-time.
And the new certificate and DNS records are to make the proxy look legit to the Zoom client, which would otherwise not accept TLS connections. Especially if there are DNS records which specify which CA is used for the certificate.
If you're thinking of CAA, those records are not for anybody except the CAs. They're an indication to the CA "You may/ may not issue for these names" and explicitly never an instruction to clients about what's trustworthy.
It's unusual but completely sound to have CAA set to forbid all CAs, switch it to allow just one CA, get a certificate issued, then put it back to blocking them all again for a week or months. I'm not recommending that procedure, but it's sound and if any software can't handle that the software is broken.
The idea here is that all the public CAs are trustworthy but their procedures may not be a good match to your particular way of doing things. For example if a CA does ACME http-01 proof-of-control (like Let's Encrypt) and you let customers run arbitrary stuff on port 80 on your machines that's a bad combination, probably you should get your certificates from a CA which doesn't use ACME http-01 and restrict CAA.