Re: Maemo 5 as a vulnerability / "hacking" victim
 

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.

Of course, although my implementation is quite safe from passive attacks due to very low traffic.

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?

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?

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.

Thx for responding btw:)

Re: Maemo 5 as a vulnerability / "hacking" victim
 

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 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.

Re: Maemo 5 as a vulnerability / "hacking" victim
 

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.

That is indeed correct, and I wouldn't have it any other way;)

Thanks, the latter is done via the client-to-client option;)

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.

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.

Re: Maemo 5 as a vulnerability / "hacking" victim
 

Here is the quote from openvpn manual:

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.

Re: Maemo 5 as a vulnerability / "hacking" victim
 

Wow. This is getting very interesting. Thanks good Sirs.


Nokia didn't specify about MicroB property but I'm pretty sure MicroB is closed-source as a property of Nokia.

Maybe here's an answer to the sandboxing idea (again, maybe):
http://browser.garage.maemo.org/docs/build_howto.html

White paper of MicroB showing internal architecture:
http://browser.garage.maemo.org/docs/browser_paper.html

Lemme know it this helped you.

Re: Maemo 5 as a vulnerability / "hacking" victim
 

Gecko = Mozilla Engine

Re: Maemo 5 as a vulnerability / "hacking" victim
 

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.

Re: Maemo 5 as a vulnerability / "hacking" victim
 

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

Re: Maemo 5 as a vulnerability / "hacking" victim
 

Oh I didn't understood where you were going. I totally agree with you. Thanks.

Re: Maemo 5 as a vulnerability / "hacking" victim
 

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:

In fact, I'm not really sure what the static key mode is. Is it the non-PKI one?

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 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.