https://www.mail-archive.com/webkit-changes%40lists.webkit.org/msg255060.html

Expected Behavior:

When a device is set to "Not Protected", eBlocker should immediately cease sending gratuitous ARP replies for that host, stop proxying outbound HTTP/HTTPS traffic, and allow direct Layer 2/3 routing to the actual default gateway.

Current Behavior: 

Certain web links time out and fail to load. Or in my case, I was restoring an iPhone in recovery mode via iTunes/Apple Devices/3uTools and I kept getting itunes error 1109. After extensive poking around and confirming that my eBlocker was disabled, the only way for me to restore and wipe my iPhone via iTunes was to power off my eBlocker and my iPhone restored successfully and the webpages I was trying to view loaded correctly. 

I'll do that. Thanks for your help.
I'll let you know if the error is fixed after I try a new SD card.

Best regards,
Thomas

I would wait for the next release eOS 4.1 which we are currently testing. It should come out in a few weeks. With that you have the option to backup all settings. So it should be very easy to replace the card.

Hi Boris,
I’m only getting back to you today because everything has been working perfectly for the past few days.
It happened again today.
The update progress bar is running, but it’s stuck at 0%.
I opened the dashboard and accessed the settings from there.
When I tried to restart via System > Restart, the eBlocker rejected the attempt with the message: “The eBlocker cannot be restarted at this time.” .
After that, the message appeared again: “Please wait, the system is being updated: 0% complete. Please do not disconnect the power supply.”
Only by disconnecting the power supply was I able to get the eBlocker to restart.

Could the power supply or the SD card be faulty?

Best regards, Thomas Beier


Translated with DeepL.com (free version)

For details, see for example eMudhra Intermediate CA Compromise.

The problem is that the private keys are now public and anyone can issue server certificates with these CAs.

Although the CA certificates with weak keys were revoked, I tested whether eBlocker could be vulnerable to server certificates issued by them.

The short answer is: no, eBlockerOS 3 and 4 are not vulnerable to these CA keys.

More details below...

There could be two potential attack vectors on eBlocker:

• Fake the server certificate for any domain if eBlocker is intercepting HTTPS.
• Fake the certificates of eBlocker's license and update servers: my.eblocker.org, api.eblocker.org and apt.eblocker.org.

Fake any server certificate

eBlocker's certificate validator downloads certificate revokation lists (CRLs) and prevents HTTPS connections to servers with certificates signed by one of the eMudhra CAs with weak keys.

Testing: enable HTTPS and go to https://emudhra.we-have-a-problem.com.

Tests with eBlockerOS 3.2.3 and 4.0.3 were successful: server certificates issued by the revoked eMudhra CAs were not accepted by eBlocker.

Fake license and update server certificates

The license server uses eBlocker's own certificate CAs and roots. If eBlocker tries to connect to a server (my.eblocker.org or api.eblocker.org) with a fake certificate, the Java client on the eBlocker does not allow the connection:

PKIX path building failed: ...
unable to find valid certification path to requested target

What about the update server at apt.eblocker.org?

The update server also has a certificate issued by eBlocker's own CA. If the system updater apt-get connects to a fake server it throws the error:

Certificate verification failed: The certificate is NOT trusted.
The certificate issuer is unknown.
Could not handshake: Error in the certificate verification.

But: even if it would be possible to get the eBlocker to connect to a fake update server, the code signatures would not match with eBlocker's GPG code signing keys, so updates would fail anyway.