You may want to check the openvpn page on that topic. But you can not eliminate the server as a factor.
I don't want to neglect that possibility, I just want to look at the topic from Maemo's(the client's) angle. If the server is compromised the client is as well, there is no question about that. The whole idea is what can be done client side to enhance security.
Please be more specific, because I am not sure if you are referring to the session establishment, or later integrity checks, when data are actualy sent?
I meant kind of meant both, but more of the latter; does HMAC auth protect the client from DoS and portscan by dropping non-authenticated packets before processing?
The posted exploit does not recover username/passwords from within browser. It basically replaces legitimate login page.
The attacker poses as a default router, by producing massive number of arp messages in order to confuse the victim about default gateways actual ARP address.
The attacker itself is configured to forward any incoming traffic to the legitimate router. The sslstrip is used in-between to replace unencrypted HTML login pages, with ones that can be used to log username/passwords.
Once the username/password is recovered, the information is used to create a legitimate session, so victim firmly belives it is secure, since the SSL is established and locker is visible.
I did get that, very clever actually. But the question was wether or not it's possible to obtain passwords using keylogger for another browsing instance, IM account and whatnot. Lets assume user wanders(via phishing or DNS spoof) to a site that has a keylogger script.
I meant kind of meant both, but more of the latter; does HMAC auth protect the client from DoS and portscan by dropping non-authenticated packets before processing?
I would not go for static key mode, since in this case the same keys are reused on each connection.
It is better to use SSL based mode, SSL itself enforces the generation of shared secret each time. Thus created secure channel is used to exchange the keying material which is used to dynamically generate shared secrets.
Yes exactly, to create a chroot jain in case server or another client get compromised. Is it possible client side only assuming server is a win box?
Yes you may do that, in addition you can isolate clients within VPN.
The possible intrusion vector may be the built-in browser. I don't know which version of Gecko is used, but I am pretty sure the there were severe problems with firefox pre-3.6 versions.
Closed-source Flash might also be interesting for poking around.
I would not go for static key mode, since in this case the same keys are reused on each connection.
You must have misunderstood me on this one, let me call openvpn.net to help explain what I meant:
'Hardening OpenVPN Security
One of the often-repeated maxims of network security is that one should never place so much trust in a single security component that its failure causes a catastrophic security breach. OpenVPN provides several mechanisms to add additional security layers to hedge against such an outcome.
tls-auth
The tls-auth directive adds an additional HMAC signature to all SSL/TLS handshake packets for integrity verification. Any UDP packet not bearing the correct HMAC signature can be dropped without further processing. The tls-auth HMAC signature provides an additional level of security above and beyond that provided by SSL/TLS. It can protect against:
* DoS attacks or port flooding on the OpenVPN UDP port.
* Port scanning to determine which server UDP ports are in a listening state.
* Buffer overflow vulnerabilities in the SSL/TLS implementation.
* SSL/TLS handshake initiations from unauthorized machines (while such handshakes would ultimately fail to authenticate, tls-auth can cut them off at a much earlier point).
Using tls-auth requires that you generate a shared-secret key that is used in addition to the standard RSA certificate/key:
openvpn --genkey --secret ta.key'
To my current understanding this option uses a SHA1 hash of secret ta.key file and the packet data to verify that packet comes from source and that it hasn't been tempered with and places this hash in the packet header. I think it also gets encrypted with the cypher of your choice, but that I can't tell for sure.
It is better to use SSL based mode, SSL itself enforces the generation of shared secret each time. Thus created secure channel is used to exchange the keying material which is used to dynamically generate shared secrets.
That is indeed correct, and I wouldn't have it any other way
The possible intrusion vector may be the built-in browser. I don't know which version of Gecko is used, but I am pretty sure the there were severe problems with firefox pre-3.6 versions.
That I am also worried about and we are not likely to recive any security updates for MicroB, unless in CSSU. I don't even know wether MicroB is open. It would be a good thing if some of our 'seasoned' members looked into this.
Closed-source Flash might also be interesting for poking around.
Probably the weakest link as there is no way we can apply updates to that.
Please note that I am no way an expert in either networking nor security, I just have a genuine interest in these areas. I just started reading up on both very recently. I have some knowledge of ITC from my past, but I wasn't very interested until I actually joined this community. So that being said any positive criticism is hugely welcome.
Using tls-auth requires that you generate a shared-secret key that is used in addition to the standard RSA certificate/key:
openvpn --genkey --secret ta.key'
Here is the quote from openvpn manual:
Originally Posted by
In static-key encryption mode, the HMAC key is included in the key file generated by --genkey. In TLS mode, the HMAC key is dynamically
generated and shared between peers via the TLS control channel. If OpenVPN receives a packet with a bad HMAC it will drop the packet.
HMAC usually adds 16 or 20 bytes per packet. Set alg=none to disable authentication.
In short, this is used for static keys when used with UDP. For dynamic (TLS based) you do not need it.
My guess is that the shared secret is used to feed IV of hash function (MD5, SHA1, SHA224, SHA256, SHA384, SHA512), although I would have to inspect source code to see what is actually going on.
In case of SHA1 20 bytes * 8 bits, gives you 160 bits.
Instead of putting SHA1 to the outer package, I would prefer to keep it together with plain-source, than encrypt everything together. That would provide more security.
Any poking around with the cipher text, would cause inner SHA1 hash to fail.
The drawback to this approach is the need to decrypt each packet, than calculate SHA1 to detect the "faulty" packet.
That I am also worried about and we are not likely to recive any security updates for MicroB, unless in CSSU. I don't even know wether MicroB is open. It would be a good thing if some of our 'seasoned' members looked into this.
Probably the weakest link as there is no way we can apply updates to that.
.
Nokia didn't specify about MicroB property but I'm pretty sure MicroB is closed-source as a property of Nokia.
Yeah I know that part, but as being a 'fork' of Firefox it has a lot of source tweaks that appear to be closed. I didn't see microb source code available anywhere. Even if it's based in the same engine, the rest of it's a part of Maemo's closed source parts.
That sucks big time.
Yeah I know that part, but as being a 'fork' of Firefox it has a lot of source tweaks that appear to be closed. I didn't see microb source code available anywhere. Even if it's based in the same engine, the rest of it's a part of Maemo's closed source parts.
That sucks big time.
I don't know about the facts at the moment. But consider this: they wanted to use gecko in order to have a device with good and stable browser.
Developing such piece of software requires years and huge resources. The complexity of that effort is significantly higher than a sum of all source code created by Nokia for 4 devices so far.
So they have resorted to using existing product based on MPL licence which is far less restrictive to source closing. They may have done some patches, but the scale of changes is negligible compared to original Gecko.
In addition, the company culture dictates rapid releases of new devices, so I can bet they did not spend too much time patching security issues.
By following this logic you can expect "Mozilla Engine" to suffer majority of problems identified within original Gecko engine.
Sure they can continue to merge with the original project, but this did not happen too often for any of the devices. Once the support has stopped, no new updates have appeared and it is reasanoble to expect that some exploits will work in MicroB
I don't know about the facts at the moment. But consider this: they wanted to use gecko in order to have a device with good and stable browser.
Developing such piece of software requires years and huge resources. The complexity of that effort is significantly higher than a sum of all source code created by Nokia for 4 devices so far.
So they have resorted to using existing product based on MPL licence which is far less restrictive to source closing. They may have done some patches, but the scale of changes is negligible compared to original Gecko.
In addition, the company culture dictates rapid releases of new devices, so I can bet they did not spend too much time patching security issues.
By following this logic you can expect "Mozilla Engine" to suffer majority of problems identified within original Gecko engine.
Sure they can continue to merge with the original project, but this did not happen too often for any of the devices. Once the support has stopped, no new updates have appeared and it is reasanoble to expect that some exploits will work in MicroB
Oh I didn't understood where you were going. I totally agree with you. Thanks.
In short, this is used for static keys when used with UDP. For dynamic (TLS based) you do not need it.
You got me confused now I had to check my .conf file; but
I think tls-auth /etc/openvpn/ta.key 1 stands for the dynamic one.
So the preshared ta.key file is needed probably for this very reason:
My guess is that the shared secret is used to feed IV of hash function (MD5, SHA1, SHA224, SHA256, SHA384, SHA512), although I would have to inspect source code to see what is actually going on.
In fact, I'm not really sure what the static key mode is. Is it the non-PKI one?
Instead of putting SHA1 to the outer package, I would prefer to keep it together with plain-source, than encrypt everything together. That would provide more security.
Now I'm not sure how exacly they implemented this; if hash is encryped seperate from data or together. But I know if an attacker changes a single bit in the packet the hash will fail.
The drawback to this approach is the need to decrypt each packet, than calculate SHA1 to detect the "faulty" packet.
The whole idea is that the server has to be able to be extract the hash from the packet in order to filter out dodgy UDP packets to save the cypher and the TCP/IP stack from further processing. Sort of not letting your 'pipe' get 'clogged'. Thankfully, this is just the first line of defence. That being said as long as the hash can be extracted from the packet it would be possible to encrypt them together, but I'll try to read up on this later.
PS: MD5 is not recomended due to vulnerabilities and some other problems.
