Indy https Dropbox 401 issue

[noisy_master]

Hallo Gemeinde,

vorab erstmal ein glückliches, gesundes und erfolgreiches Jahr 2024!

Ich hätte da gerne mal wieder ein Problem:

Ich habe ein kleines Progrämmchen, das via Indy TIdHttp mit TLS 1_2 Dateien auf Dropbox hochlädt. Funktioniert auch wunderbar....meistens!
Auf allen Rechnern ist die gleiche Software und die gleichen OpenSSL .Dll's(und die gleichen Dropbox Credentials). Aber auf manchen Rechnern (unabhängig ob Win7, 10, 11)(konkret 4 von 42 Rechnern) bekomme ich ein "HTTP/1.0 401 Unauthorized" beim Anmelden an Dropbox(Die Anmeldung im Browser funktioniert)....

Somit scheint es irgendwie an den "Windowssettings" zu liegen....

Hat irgendwer eine Idee, woran es konkret liegen könnte, bzw. wie ich Abhilfe schaffen kann?

Freue mich schon auf viele kreative Ideen ;-)

Gruß

[Kas Ob.]

Hi,

I witnessed such failure in general but not with DropBox per se, the cause was installed Antivirus with settings to inspect encrypted connection, it will hijack HTTPS sessions and replace the certificate with its own.

To identify/check/verify this guess/theory, ask one of the failed client to see if he visited a site like delphipraxis.net, then what does his browser report the certificate issuer ?

the real certificate is issued by

Code:

Common Name (CN)   Thawte RSA CA 2018
Organization (O)   DigiCert Inc
Organizational Unit (OU)   www.digicert.com

If it was replaced by Kaspersky or other AV then the issuer will be different and/or the path of trust chain that leads to a root certificate is different.
Anhang 56528

[noisy_master]

Zitat:

Zitat von Kas Ob. (Beitrag 1531479)

Hi,

I witnessed such failure in general but not with DropBox per se, the cause was installed Antivirus with settings to inspect encrypted connection, it will hijack HTTPS sessions and replace the certificate with its own.

Sounds good! I'll check....BUT: shouldn't i have the same issue with the browser then?

[Kas Ob.]

Zitat:

Zitat von noisy_master (Beitrag 1531481)

Sounds good! I'll check....BUT: shouldn't i have the same issue with the browser then?

Good question !
And the answer is not always, see if browser like Chrome is using QUIC then possibly it will not intercepted by AV, that is one case.
Another case, it could be the AV had changed something in the request or the response header and violated the authentication.

In general AV with such enabled behavior intercept the traffic will not be changed or altered, but sometimes (not always) the connection belongs to some software that utilize protection against that like Signal, it will not allow such interception, like many social application, i did such protection in few projects by adding custom TLS extension as extra authentication between server-client, so even when using a certificate, my server/client connection can be checked against such interception, that about protection from an application side, there is another case where the AV insert a header declaring that the HTTP traffic had being inspected, this might lead also to violation in header signature if it was used.