discuss@lists.openscad.org

OpenSCAD general discussion Mailing-list

View all threads

Re: new startup errors

JB
Jordan Brown
Sat, Jan 25, 2025 12:29 AM

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

  • start with a simple "are updates available" check, continue with a
    shapes library, color schemes, extensions, library manager, et cetera. 
    You really do want to give people the richest possible interface by
    default, without making them wade through tons of details approving each
    feature.

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 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 - start with a simple "are updates available" check, continue with a shapes library, color schemes, extensions, library manager, et cetera.  You really do want to give people the richest possible interface by default, without making them wade through tons of details approving each feature. 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.
RW
Rogier Wolff
Sat, Jan 25, 2025 3:58 PM

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 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.
TP
Torsten Paul
Sat, Jan 25, 2025 4:29 PM

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.

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.
JB
Jordan Brown
Sat, Jan 25, 2025 8:00 PM

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.

> 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.
RW
Rogier Wolff
Sat, Jan 25, 2025 8:07 PM

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 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.
TP
Torsten Paul
Sat, Jan 25, 2025 10:23 PM

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.

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.
JB
Jordan Brown
Sun, Jan 26, 2025 6:03 PM

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.

> 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.