"Enforce HTTPS" Field for Domains to Prevent SSL Stripping?

[biolizard89]

I dislike the idea of assuming domains are only for webserving.
Can this be made generic?

The fingerprint/sha1 field is generic; it probably wouldn't be hard for an implementation to use it for SSH or something similar. The enforce field is specific to protocols that use both TLS and cleartext, but this could be applications other than HTTP... FTP comes to mind as another protocol that could use the enforce field. Obviously an SSH/FTP/whatever client would have to support these features, but that is independent from the .bit specification.

[moa]

I dislike the idea of assuming domains are only for webserving.
Can this be made generic?

I think this is what we just did by making it generally applicable for all TLS/SSL connects and not just HTTPS ... or maybe I'm misunderstanding the question?

@biolizard ... so how would a ssh connection using nmcsec work?

Code: Select all

ssh user@name.bit

would look up d/name (locally for example) and find the tls cert fingerprint .... then what?

[biolizard89]

I dislike the idea of assuming domains are only for webserving.
Can this be made generic?

I think this is what we just did by making it generally applicable for all TLS/SSL connects and not just HTTPS ... or maybe I'm misunderstanding the question?

@biolizard ... so how would a ssh connection using nmcsec work?

Code: Select all

ssh user@name.bit

would look up d/name (locally for example) and find the tls cert fingerprint .... then what?

Normally an SSH client will present a fingerprint to the user when it connects to a host for the first time. The user has the option to accept temporarily, cache the fingerprint, or cancel the connection. When a fingerprint matches the cached fingerprint, the client will connect without warning the user; when a fingerprint doesn't match the cache, the client will notify the user that it doesn't match and refuse to connect.

A .bit-aware SSH client would check fingerprints against the Namecoin blockchain instead of checking against the local fingerprint cache, so the user wouldn't have to manually approve new servers, and if the server legitimately changed its fingerprint, the user wouldn't be warned as long as the blockchain entry was changed accordingly.

[moa]

I dislike the idea of assuming domains are only for webserving.
Can this be made generic?

I think this is what we just did by making it generally applicable for all TLS/SSL connects and not just HTTPS ... or maybe I'm misunderstanding the question?

@biolizard ... so how would a ssh connection using nmcsec work?

Code: Select all

ssh user@name.bit

would look up d/name (locally for example) and find the tls cert fingerprint .... then what?

Normally an SSH client will present a fingerprint to the user when it connects to a host for the first time. The user has the option to accept temporarily, cache the fingerprint, or cancel the connection. When a fingerprint matches the cached fingerprint, the client will connect without warning the user; when a fingerprint doesn't match the cache, the client will notify the user that it doesn't match and refuse to connect.

A .bit-aware SSH client would check fingerprints against the Namecoin blockchain instead of checking against the local fingerprint cache, so the user wouldn't have to manually approve new servers, and if the server legitimately changed its fingerprint, the user wouldn't be warned as long as the blockchain entry was changed accordingly.

Right, I forgot about accepting certs the first time in ssh. The pubkeys are held in .ssh/known_hosts and looks like they can include port information (usually 443) and key type (e.g. ssh-rsa), probably other stuff also.

While we are thinking TLS through I'm a bit nervous about the vulnerability of expired names being given a new fingerprint by an attacker ... I know that "people should not let their names expire" is default setting on this one and I agree, but it seems like we are hinging all the security on that postion.

I know that there is an expiry in the certs also, so as a first best practice should we look towards making certificate expiry and name expiry harmonised?

And are there also some other options? ... We have quite bit of space in value field to put additional sec. info.

[phelix]

I dislike the idea of assuming domains are only for webserving.
Can this be made generic?

I guess you are not talking about a new protocol to Nmcontrol...

https with Nmcontrol as local CA?