Due to the recent controversy about AOLs recent change in TOS I started to wonder how this plug-in exchanged keys between users, so I loaded up a packet sniffer and noticed that the keys were being exchanged through AOL's server. Doesn't this make the plug-in completely useless when trying to have a private communication from AOL? I don't pretend to be a encryption expert or anything, however from what I know about man in the middle attacks it seems that this design is flawed. I believe that a better way would be to build a direct connection between users and then transfer the keys that way, however then your IP address are exposed.
If someone can shed some light on this it would be appreciated, thanks.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
absolutely. passing the public keys through AOL doesn't tell them anything about your private key, but it does give them the opportunity to replace the keys with their own and act as a man in the middle.
It is essential that you verify the ownership of the key you get by comparing key fingerprints over a secure channel: telephone, gpg-encrypted email, etc.
Chris
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
What would be better would be if gaim-encryption supported standard GPG keys stored in the standard way; note that Thunderbird/Enigmail, GPA, and SeaHorse all share the same list of GPG keys because they're all stored in ~/.gnupg or an appropriate directory on Windows. LDAP keyservers would be used to get keys.
This model would require that the e-mail address be exchanged securely, although it'd be easier to handle than the fairly standard key exchange. E-mail addresses can be exchanged with the IM handle, or they can be exchanged in deformed human readable format. An automated process won't typically notice i_am_god (at) foo X bar as i_am_god@foo.bar, or any other random deformation you come up with. A human can do it; but a human attacker would create visible latency. Unfortunately that latency wouldn't always be noticed, since the two sides are exchanging messages and don't see how long it takes to reach the other side.
Utilizing GPG keys is still better than these on-the-fly session keys; even SSL connections are typically backed by a key verified at a certificate authority.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Due to the recent controversy about AOLs recent change in TOS I started to wonder how this plug-in exchanged keys between users, so I loaded up a packet sniffer and noticed that the keys were being exchanged through AOL's server. Doesn't this make the plug-in completely useless when trying to have a private communication from AOL? I don't pretend to be a encryption expert or anything, however from what I know about man in the middle attacks it seems that this design is flawed. I believe that a better way would be to build a direct connection between users and then transfer the keys that way, however then your IP address are exposed.
If someone can shed some light on this it would be appreciated, thanks.
absolutely. passing the public keys through AOL doesn't tell them anything about your private key, but it does give them the opportunity to replace the keys with their own and act as a man in the middle.
It is essential that you verify the ownership of the key you get by comparing key fingerprints over a secure channel: telephone, gpg-encrypted email, etc.
Chris
Definitely.
What would be better would be if gaim-encryption supported standard GPG keys stored in the standard way; note that Thunderbird/Enigmail, GPA, and SeaHorse all share the same list of GPG keys because they're all stored in ~/.gnupg or an appropriate directory on Windows. LDAP keyservers would be used to get keys.
This model would require that the e-mail address be exchanged securely, although it'd be easier to handle than the fairly standard key exchange. E-mail addresses can be exchanged with the IM handle, or they can be exchanged in deformed human readable format. An automated process won't typically notice i_am_god (at) foo X bar as i_am_god@foo.bar, or any other random deformation you come up with. A human can do it; but a human attacker would create visible latency. Unfortunately that latency wouldn't always be noticed, since the two sides are exchanging messages and don't see how long it takes to reach the other side.
Utilizing GPG keys is still better than these on-the-fly session keys; even SSL connections are typically backed by a key verified at a certificate authority.