You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
DSub allows connection to subsonic backends over SSL with self-signed certs (rightly) but doesn't prompt the user which cert is used. This effectively eliminates the protection of SSL since in a MITM scenario DSub would happily accept the new cert without alerting the user.
A rudimentary form of certificate pinning could solve this without much inconvenience.
On first connection to a server with a self-signed cert, present a dialog to the user to accept or deny.
Store the cert fingerprint keyed to the domain
On subsequent connections:
3.a if the cert presented matches the fingerprint, don't alert the user
3.b if the cert presented doesn't match, alert the user to accept or deny. On accept, replace stored fingerprint with the new one.
This won't protect people who simply click through warnings, but is similar to the pattern browsers follow with self-signed certs.
The text was updated successfully, but these errors were encountered:
DSub allows connection to subsonic backends over SSL with self-signed certs (rightly) but doesn't prompt the user which cert is used. This effectively eliminates the protection of SSL since in a MITM scenario DSub would happily accept the new cert without alerting the user.
A rudimentary form of certificate pinning could solve this without much inconvenience.
3.a if the cert presented matches the fingerprint, don't alert the user
3.b if the cert presented doesn't match, alert the user to accept or deny. On accept, replace stored fingerprint with the new one.
This won't protect people who simply click through warnings, but is similar to the pattern browsers follow with self-signed certs.
The text was updated successfully, but these errors were encountered: