Controllo KOBD2, STG e password via internet

Ciao,

Esiste un file di log di Kobd2check che posso consultare rapidamente per capire perché il controllo STGCheck tramite Internet richiede sempre la password?

Suppongo che il file .exe non sia stato abilitato nel firewall. Oppure, è possibile che il mio account non sia ancora autorizzato a utilizzare questa funzione?

Per test, ho disattivato temporaneamente la funzionalità di firewall, ma la finestra di login continua a comparire, anche se sono sicuro che le credenziali di accesso per shop.dieselschrauber.org siano corrette.

Ciao.
Olio.

Ciao,

Quale sistema operativo è installato sul computer?
Tutto funziona all'interno di una macchina virtuale che potrebbe essere resettata periodicamente?

La richiesta della password (per il controllo CVN e il controllo della versione del software) è sempre attiva per impostazione predefinita quando il computer ha accesso a Internet.

Ritorna immediatamente la finestra di dialogo per l'inserimento della password dopo l'inserimento? In caso affermativo, non è stato possibile connettersi al server "Dieselschrauber": potrebbe essere un problema di firewall, malware presente sul computer che intercetta/spia le connessioni TLS, oppure semplicemente username/password errati.
Se non funziona e la finestra di dialogo per l'inserimento della password compare ogni volta che si avvia KOBD2Check, significa che il token di accesso fornito dal server non è stato in grado di essere salvato nel registro di sistema.

Cordiali saluti, Rainer.

Ciao Rainer,

Il software funziona correttamente su un notebook con Windows 10.

Il malware può essere categoricamente escluso sono troppo coinvolto nella protezione dei dati.

La richiesta della password ricompare subito dopo l'inserimento. I dati di accesso sono stati verificati e funzionano correttamente sul sito.

L'indirizzo IP del server è codificato direttamente nel dispositivo? Infatti, per impostazione predefinita, le richieste dirette di indirizzi IP verso Internet vengono bloccate dai router Fritzbox di AVM.
Poiché la disattivazione del firewall di Windows non ha portato a miglioramenti. Al momento, non ho altri componenti hardware per poter effettuare dei test incrociati.

KData-Scope segnala anche che la versione è obsoleta, ma non riesce a trovare alcuna versione sul server.

Scope è installato nell'ultima versione. Probabilmente, sono stati inseriti dei dati di scadenza (expire data) nella configurazione?

Ciao Rainer,

Ho lasciato passare un po' di tempo, alcune "settimane", per capire la causa.

Purtroppo, la query continua a non funzionare.

Sistema operativo: Win10.
Accesso al negozio: OK.
MS Defender Firewall disattivato: OK.
Scansione antivirus: MS Buildin.
Non ci sono malware nelle mie reti.


Torno ancora alla mia domanda: come posso accedere ai log? Oppure, come posso capire con Wireshark cosa sta facendo esattamente KOBD2Check? Perché vedo un tentativo di connessione tramite TLS V1.2 all'indirizzo IP 178.209.53.204.

Nella catena di certificati del vostro server web, vedo la Comodo CA, ma sembra che il certificato sia scaduto il 30 maggio 2020.

Ciao,

No, il mio certificato è valido fino al 30.11.2020, quindi la connessione che il tuo computer sta cercando di stabilire potrebbe già essere stata indirizzata altrove.

Controlla pure:

https://www.grc.com/fingerprints.htm

Cordiali saluti, Rainer.

Ciao Rainer,

No, non il certificato del vostro server, ma il certificato radice della vostra autorità di certificazione (CA) che ha emesso il certificato per dieselschrauber.org:

Serial 27:66:EE:56:EB:49:F3:8E:AB:D7:70:A2:FC:84:DE:22
Autorità di certificazione COMODO RSA.

Il vostro server web sta fornendo una catena di certificati, e sembra che questa catena contenga ancora, in modo cumulativo, un vecchio certificato radice (Root CA). Come si può notare nel rapporto di test sottostante, il server web sta fornendo diversi percorsi.

https://www.ssllabs.com/ssltest/analyze.html?d=dieselschrauber.org

Si potrebbe anche dare un'occhiata ai vecchi protocolli TLS .

Grazie per l'avviso, dovrò dare un'occhiata... Finora, né il mio telefono né nessun altro laptop hanno riscontrato problemi.

Cordiali saluti, Rainer.

Schrauber.Guru ha scritto:

Ciao Rainer, No, non il certificato del vostro server, ma il certificato radice della vostra autorità di certificazione (CA) che ha emesso il certificato per dieselschrauber.org: Serial 27:66:EE:56:EB:49:F3:8E:AB:D7:70:A2:FC:84:DE:22 Autorità di certificazione COMODO RSA. Il vostro server web sta fornendo una catena di certificati, e sembra che questa catena contenga ancora, in modo cumulativo, un vecchio certificato radice (Root CA). Come si può notare nel rapporto di test sottostante, il server web sta fornendo diversi percorsi. https://www.ssllabs.com/ssltest/analyze.html?d=dieselschrauber.org Si potrebbe anche dare un'occhiata ai vecchi protocolli TLS

.
Ciao,

Beh, non è un problema, dato che tutti i sistemi operativi rilevanti utilizzano certificati root più recenti.

A parte questo, il problema non riguarda il mio server o la sua configurazione, ma la catena di certificati di Comodo.

A prescindere da tutto, il test di certificazione SSL/TLS per i meccanici di motori diesel è completamente irrilevante; funzionerebbe comunque in modo sicuro e affidabile anche se si utilizzasse il protocollo HTTP.

L'identificazione e la verifica delle pagine dei partecipanti non si basano su SSL o TLS.
Per questo motivo, non è possibile intercettare le comunicazioni tramite la decrittazione di SSL/TLS, come avviene spesso in molte reti aziendali.

Se il test della licenza fallisce, puoi presumere che la connessione dati sia stata compromessa e che qualcuno possa intercettare il tuo traffico HTTPS.

Se provi di nuovo e mi indichi il momento in cui si verifica l'errore, posso dirti se il problema è dovuto a credenziali di accesso errate o se la richiesta di licenza viene rifiutata in una fase precedente.

Cordiali saluti, Rainer.

Buonasera,
Anche se sono nuovo qui, vorrei comunque comunicare che ricevo sempre lo stesso prompt seguito dallo stesso messaggio.

Ho anche Windows 10 versione 18363.959, ho disattivato/riattivato il firewall di Windows, ho attivato/disattivato Windows Defender, e ho anche una Fritzbox, ma vorrei escludere anche questa, dato che l'utilizzo di un hotspot del telefono non porta alcun miglioramento.

Suppongo che KOBD2Check dovrebbe inviare l'indirizzo email e la password a un server (dove avviene l'autenticazione), cosa che, a quanto pare, non funziona nemmeno nel mio caso.
Lavoro nel settore IT e, a mio parere, è molto probabile che l'intercettazione di comunicazioni da parte di terzi sia esclusa. (Non intendo commentare ciò che Microsoft intende fare con Windows).

Cordiali saluti,
Markus.

Ciao,

Di solito, il problema è causato da altri software installati nel sistema Windows.
Ad esempio, uno strumento per il confronto virtuale delle prestazioni dei computer.

L'effetto descritto non si è mai verificato in precedenza su una nuova installazione di Windows.

Potrei anche immaginare che i caratteri vengano filtrati durante l'inserimento della password, e che le implementazioni possano essere diverse tra il sito web e il programma.
Tuttavia, è facile verificarlo richiedendo una nuova password al negozio.

E sempre molto popolare: l'indirizzo email viene utilizzato come nome utente, ma è importante fare attenzione alla differenza tra maiuscole e minuscole!
[email protected] non è la stessa cosa di [email protected], anche se entrambe le email potrebbero indirizzare allo stesso account di posta elettronica.

Cordiali saluti, Rainer.

Caro Rainer,

Grazie per l'informazione! Dato che posso escludere anche un problema legato alla coda, potrebbe trattarsi della mia password, che è probabilmente più complessa.
Mi piacerebbe provarlo e vi contatterò di nuovo a riguardo!

Cordiali saluti,
Markus.

Caro Rainer,

La password è stata ripulita dai caratteri speciali e ora funziona perfettamente.
Grazie mille per l'informazione!
Sarebbe possibile, in una versione futura, supportare password più complesse, oppure rendere pubblico l'insieme dei caratteri utilizzabili per le password?

Cordiali saluti,
Markus.

Fenix_ARE-C2 ha scritto:

Caro Rainer, La password è stata ripulita dai caratteri speciali e ora funziona perfettamente. Grazie mille per l'informazione! Sarebbe possibile, in una versione futura, supportare password più complesse, oppure rendere pubblico l'insieme dei caratteri utilizzabili per le password? Cordiali saluti, Markus

.
Ciao Markus, ottimo feedback! Posso chiedere quali caratteri speciali erano presenti? Sì, dovrò dare un'occhiata al codice e sincronizzarlo. L'obiettivo è che si possano inserire solo i caratteri ammessi e che sia chiaro quali sono.

Dopo un'analisi del codice, sul server tutti i caratteri sono accettati come password. Lo stesso vale per il client Windows. La lunghezza massima della password è di 32 caratteri.
Il sito web supporta la codifica UTF-8, mentre il controllo di Windows comprende solo ASCII. Potrebbe essere questo il problema.

Cordiali saluti, Rainer.

Caro Rainer,
In questo caso specifico, si trattava semplicemente di un ".", il che mi sorprende un po' alla luce della tua risposta.
Di solito, le password le genero tramite un gestore di password, e di solito funziona bene.
Sono sempre felice quando posso dare il mio contributo e imparare qualcosa.

Cordiali saluti,
Markus.

Ciao,

Dovrebbe essere irrilevante, ma la password non superava i 32 caratteri?

Cordiali saluti, Rainer.

Caro Rainer,

La password era addirittura inferiore a 20 caratteri. Conteneva numeri, lettere maiuscole e minuscole e un punto. La stessa password senza il punto (che era il terzo carattere) funziona perfettamente.

Cordiali saluti,
Markus.