On 1/24/2025 4:07 PM, L Michael Fraser wrote:
I was just trying to ensure that any connections to remote sites are
clearly understood and disclosed.
Yes.
EVERY external connection should be clearly "opt-in".
Mixed feelings. This is the only one that I know of for OpenSCAD, and
it's fairly obscure, so making it opt-in wouldn't bother me. (It could
be a checkbox on Edit/Preferences/3D Print.)
But in general applications can reasonably have a lot of dynamic content
All of them should be disclosed, and you should be able to disable each
of them. But should they all be disabled by default? Not sure.
On Fri, Jan 24, 2025 at 04:29:55PM -0800, Jordan Brown via Discuss wrote:
All of them should be disclosed, and you should be able to disable each
of them. But should they all be disabled by default? Not sure.
There is a difference between a "check for updates" feature that
automatically runs, and one that you pull from a menu.
As long as the user initiates the transaction, I think it is fine to
be possible by default. If it happens automatically, it is open for
debate. I'm not so paranoid that I'd say: check for updates is bad.
But there are really people who are paranoid enough to feel bad about
such things.
Say for example, that openscad has a buffer overrun on the version
number. Now someone hacks the router on a big internet
provider. Everybody whose openscad checks for updates can be
compromised! No clicks required. That's bad.
Send an EMail: "our server has detected unusual traffic, you need to
autenticate again" and 1-10% of the people will click the link. 90-99%
will say: That's a phishing attempt and throw it away. But a no-click
exploit is at least 10x more powerful.
Roger.
--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 **
** Delftechpark 11 2628 XJ Delft, The Netherlands. KVK: 27239233 **
f equals m times a. When your f is steady, and your m is going down
your a** is going up. -- Chris Hadfield about flying up the space shuttle.
** 'a' for accelleration.
On 25.01.25 16:58, Rogier Wolff via Discuss wrote:
But there are really people who are paranoid enough to feel
bad about such things.
Rhetorical question: If those people don't even care enough to
submit an issue on Github when asked, why should we care about
them?
I cared enough to still implement the flag, because I think
it's the sensible thing to do.
ciao,
Torsten.
If it happens automatically, it is open for debate.
Yes.
Say for example, that openscad has a buffer overrun on the version
number. Now someone hacks the router on a big internet
provider. Everybody whose openscad checks for updates can be
compromised! No clicks required. That's bad.
Won’t happen, because the connection is protected by TLS. Routing compromises are one of the big reasons for TLS. However, the same concern applies if somebody hacks the OpenSCAD phone-home server.
On Sat, Jan 25, 2025 at 12:00:37PM -0800, Jordan Brown via Discuss wrote:
Won’t happen, because the connection is protected by TLS. Routing
compromises are one of the big reasons for TLS. However, the same
concern applies if somebody hacks the OpenSCAD phone-home server.
Does openscad abort if the certificate fails verification? This is a
common mistake: use TLS but don't check or fail to bomb out when the
certificate verification fails.
Roger.
--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 **
** Delftechpark 11 2628 XJ Delft, The Netherlands. KVK: 27239233 **
f equals m times a. When your f is steady, and your m is going down
your a** is going up. -- Chris Hadfield about flying up the space shuttle.
** 'a' for accelleration.
On 25.01.25 21:07, Rogier Wolff via Discuss wrote:
Does openscad abort if the certificate fails verification? This is a
common mistake: use TLS but don't check or fail to bomb out when the
certificate verification fails.
Even certificate validation only ensures end-to-end encryption to the
server running the certificate, it does not help with authenticating
it. So that could still be a man-in-the-middle attack.
ciao,
Torsten.
Even certificate validation only ensures end-to-end encryption to the
server running the certificate, it does not help with authenticating
it. So that could still be a man-in-the-middle attack.
No. Two of the key steps in certificate verification are checking that the certificate was issued by a known Certificate Authority, and checking that the name on the certificate matches the name that you intended to connect to. Certificate Authorities verify that the person requesting the certificate own the name(s) listed on it. Absent a CA compromise or a server compromise of the private key, TLS blocks MITM attacks.
You don’t actually need certificates if all you want is encryption; the key exchange protocols magically share a key in a secure way. (Look up Diffie-Hellman.) But that only defends against snooping; it doesn’t get you authentication and so alone is vulnerable to MITM.