08-04-2009, 07:58 PM
|
|
|
Join Date: 01-16-2005
|
|
Location: New York
|
|
PDAPhone: Pre and BB 8820
|
|
Carrier: Sprint / TMobile
|
|
Headset: m710
|
| Posts:
410 |
 |
Quote:
Originally Posted by buggsbuny
First off, anyone using a self signed certificate will have nothing but problems...period. Importing the cert into a PDA or PC and then "trusting" it defeats the purpose of having a cert. If you aren't an Exchange guru or a security guru like me, you either don't care or just think that its plain stupid since its stopping you from getting your mail.  The whole purpose of using certs is to verify the identity of the server by comparing keys stored on a public server (like Verisign, GoDaddy, etc). Using a self signed cert and then telling users to simply "trust it" is like putting on a name tag that says "God" and now telling everyone you are really God...just trust me on this. That is why a self signed cert is pointless when you use it on the Internet. You have no way of telling if it is indeed the real deal since you elminiated any back checking. |
That is absolutely incorrect. While you are correct that there is no WELL KNOWN third party 'certifying' that these SSL are in fact legitimate, they are still properly validated by the root cert you place in the certificate store on your Pre (and Windows Mobile device). The extra step you have to take in this case is to install a root cert for the CA that created this certificate. The public key in the SSL certificate still needs to be authenticated by a private key. This is perfectly safe. Verisign does the same thing - it's just that Verisign was the company that signed the SSL cert in the first place and they are big enough to be installed in every device's pre installed list of root certs. I'm no expert on this myself, but you claim to be so you should know this.
Quote:
Originally Posted by buggsbuny
The Pre does not support the ability to have a mandatory locking mechanism. Meaning you can make an EAS policy force a device to use a PIN number or password to lock itself after a certain amount of time. But if the device does not support this, you will get errors on the first sync attempt. The whole purpose is that if some drunk engineer leaves his PDA at a bar or at the airport lounge, nobody can read his emails, powerpoint presentations, etc. You would be surprised how many things are leaked out from pure stupidity like that.
|
After the 1.1. update it does, however I'm disappointed in how it does operate. While it can connect fine to an exchange server that requires password and locking timeouts, it still does not deviate from it's original practice of locking every time the screen goes off. Unfortunately Palm tied the PIN lock with the screen timeout, so the longest you can go without locking your phone is 3 minutes - and only if its because you allow the screen to stay on that long. Another failure is the security policies 'stick' with the phone long after it loses or deletes its relationship with exchange. I tested this the first night 1.1 was out hoping I could make my phone not lock for 30 or so minutes, however it retained the auto lock when the screen is turned off and when I tried to remove these settings (tried on the server side, tried on the Pre, tried removing the relationship with the exchange server) it proved to be impossible. I'm now stuck with no Exchange server security policy but a phone with a PIN lock it thinks is being forced on it...
I suppose I could perform a hard reset but I'd really rather not at this time (don't want to go through the rooting process again...). Overall, exchange performs decently besides the security issues I've had and the calendar hangs when making edits to the exchange calendar. I'll be very happy with exchange support once those are taken care of. |
|
|
|
|