Error 2051

[jnever1]

I'm initiating this thread to bring awareness to a certain family of Web 1.0 based errors specific to HTTPSecure networks. I bring this issue here because Palm live tech support was as helpful in blame shifting as ever...

I receive this error when attempting to gain throughput access to my college wi-fi network. By throughput I mean that I am already part of the public network, having obtained an IP, DNS, SubNet etc, but must log in https style before being able to check my e-mail, listen to shoutcast radio, get on the web etc.

The 1.2.1 process involved connecting to the wi-fi network in the typical way, then attempting to browse the web. An intercept page would appear stating something to the effect of Re-Direct to LogIn page. I would log in. All would be good.

After the 1.3.1 update, the redirect breaks, producing the "Unable to load page [Error 2051]" message.
(I tried the standard restart. Full erase. webOSdoctored back to 1.03 --> untainted update to 1.3.1. Nothing.)

Palm chat tech support only proved that "Austin" REALLY wanted it to be the school's fault. I asked him to weigh the likelihood of an overnight, unannounced, campus wide network protocol change versus a compatibility hick-up. Guess how the Palm rep voted?

I've seen similar posts of similar problems with respect to Error 2035 on the web but to no conclusion.

Maybe I have the freak phone that doesn't play well with others at 1.3.1 but the functionality flaw was enough for me to revert back to 1.2.1.

If anyone out there could offer an unbiased explanation of how the browser could fail to negotiate an https redirect under 1.3.1 while suceeding, one day earlier, at 1.2.1, I would greatly appreciate the comp-sci lesson.

[sracercelica]

I have been getting that error message a lot since installing the new update. It is very annoying and for me it is happening all the time when connected via Wifi, either home or at work.

[alex.dobeck]

I haven't had any problems since the 1.3.1 update but it sounds to me like the redirect your school does likely a non-standard (but supported by IE) attempt which other browsers are probably lenient about, (have you tried this on Chrome or Opera?) and with the latest patch the updated Browser just doesn't like it and throws an error instead of letting you continue, could be an oversight, or it could be to protect you from memory leaks.

Anyway, you could request a patch which overrides the new browser with the old, could be easy (depends on how much interdependent code was placed in the latest patch). Otherwise you'll have to wait for another update.

[jnever1]

Thanks, alex. I appreciate your assessment. To the benefit of Palm, I'm going to assume that my school is offering right handed 1.3.1 a left handed hand shake. As for asking for a patch - i think I'll just sit this one out. Fewer headaches = a better user experience in my book.

[35whl21]

Having poked around after I got the same error accessing my home Debian-based server (and initially blaming 1.3.1 for all my woes), I'm now wondering if the problem may come from something done to address this man-in-the-middle vulnerability (CVE - CVE-2009-3555 (under review)). By sheer coincidence the Debian update for this issue and my Pre update to 1.3.1 occurred on the same day and now I can't access any SSL protected pages on my server from the Pre. (IE and Firefox are both working fine). So it's actually possible that the guy from Palm was right and that the change occurred on your school's server end. It's still not a good thing (to say the least) that the Pre's browser can't handle something that both IE and Firefox swallowed without a hiccup, but at this point I'm not at all certain that going back to 1.2.1 would help anyhow.

[jnever1]

35...
Thanks for your input. I actually downgraded my pre to 1.2.1. Webdoc style. Total clean slate. My school network is back to functional. (I'm on it as I write.) I'll look at the MitM post but i'm burned on reloading patches and brews for the time being. If I could be 100% on the log-in I would jump but nothing looks that likely as of today. However, i'm a mandriva user. Linux will win, it just takes time.

EDIT
Ok... looked at the article regarding SSL/TSL Man-in-the-Middle attact vulnerbilities.
My guess is the following: My school uses the vulnerable SSL/TSL process. 1.3.1 'fixes' the problem by denying access (in an insecure situation).

Well, ok... thanks, Palm, for the band-aid but I was unaware that I was bleeding!

If this is indeed the case then I find the 1.3.1 SSL/TSL fix to be nothing more elegant than shutting off the water main to stop a leaky faucet drip. I would have preferred the power of decision be left to myself and/or my school (School obviously being ok with the vulnerability) to deny access/functionality. I hate to side with Microsoft, but even IE gives you the option to proceed in insecure places.

It's kind of like the Palm-DMV taking my license away in order to protect me from getting into a wreck. Personally, I'd prefer to take my chances and continue to enjoy my, perhaps dangerous, mobility.

[glorifiedg]

Having the same problem here. Thats no way to bypass this problem by modification of web browser with a patch or something?

Im getting realy frustrated: can't access my university wireless network neither can access moodle or the university website.

[jnever1]

Well, as much as I'd like to b and m (and I did to the Palm chat tech... all the while trying to pry info that might lead me to the aberration in code from 1.2.1 --> 1.3.1) I'm comfortable with the idea that Palm doesn't want to be known as having produced the phone/OS that allowed a "secure" network to be hacked.

That said, I reitterate that slapping a tournicate on this security leak was a BigBrother move on the part of Palm.
I'm a big kid and it would be daft of me to assume my school was unaware of its security inefficiencies. A more acceptible fix would simply interrupt navigation with a security warning and a "Do you want to procede?" - Yes/No.

Maybe if enough ppl speak up, we can get this fixed by Palm rather than hoping for some gifted, kind, guru to save the day!

[jrhackworth]

Same problem here - error 2035. I'm trying to access my records at my university. I can access my records from any computer, but not from my Pre. I can access other web pages at the university from my Pre, but when I go to the login page for records, no-go.

I read some posts speculating that it might be because of a redirect from an http to an https page. True, I am being redirected. However, I bypassed the redirect and directly typed in the https URL. No-go.

We need a Palm rep to get into this discussion. This is definitely a bug and it needs to be fixed.

[glorifiedg]

No clue on this?

[jnever1]

from New Browser Flaw Weakens EV SSL Trust - Security

EV SSL certificates were designed several years ago by certificate issuing authorities to combat the growing trust problems with normal domain validated SSL certificates (DV SSL).

A newly discovered vulnerability in the way web browsers handle high-assurance Extended Validation SSL (EV SSL) certificates may render them ineffective until browser developers fix the problem, security researchers said today.

EV SSL certificates were designed several years ago by certificate issuing authorities to combat the growing trust problems with normal domain validated SSL certificates (DV SSL), which had devolved into a low-cost, low-barrier-to-entry acquisition model. The newer EV SSL certificates are meant to assure site users that site owners have jumped through hoops and have had their identities verified as who their websites claim them to be. This assurance is provided by a green glowing bar in the browser, as opposed to the more traditional yellow lock offered by DV SSL certificates.

Unfortunately, a recent flaw discovered within the browsers themselves can actually be exploited by hackers to replicate that green glow and sniff sensitive data as it leaves the browser, says Mike Zusman, principal consultant at Intrepidus Group, who together with independent security researcher Alex Sotirov found the vulnerability.

“What Alex and I did is we came up with a tool that allows us to spoof that green badge, or that green glow of EV SSL,” Zusman says. “If you're an attacker and you happen to obtain one of the lower assurance domain validated SSL certificates that are much easier to get than EV SSL certificates you can leverage the easy certificate to spoof this green badge.”

Zusman and Sotirov will present their findings at next week’s Black Hat hacker conference. There they’ll explain how they were able to take advantage of browser vulnerabilities in order to perpetrate two different attacks that exploit user trust in EV SSL certificates. The first, which Zusman and Sotirov call SSL rebinding, is a man-in-the-middle attack that can be launched by a hacker who has taken over a wireless connection shared with the victim. The attacker can take advantage of the fundamental fact that under the hood browsers treat EV SSL and DV SSLs the same to deliver a rogue certificate that tricks the user into thinking he or she is connected to a safe site.

“Since the browsers treat them both the same, an attacker can use the DV cert in conjunction with the real site and their real EV cert to spoof the green glow and essentially sniff data coming out of the web browser without the client being alerted that anything is happening to their extended validation SSL connection,” Zusman says.
The other type of attack, labeled EV Cache Poisoning, can be perpetrated against organizations that choose to use a mixture of EV SSL and DV SSL certificates across their sites, depending on the content. Hackers can attack the low assurance areas of a site and leverage the attack in order to spoof the green glow offered by high assurance certificates.

“Essentially this is a mixed content problem, where you're mixing content that's protected with two different types of SSL security,” Zusman says. “So what this means is that the attacker compromises the lower security DV SSL site or does a man in the middle there where he's not even touching the EV-protected content. But his code is still going to be treated as EV protected, so the browser is still going to show the user the green badge.”

According to Zusman, organizations that depend on EV SSL certificates can mitigate some of their risks by discouraging users from using untrusted wireless networks and by uniformly using EV SSL if they choose to run with them. But in the end, the trust issue can only be fixed at the browser level.

“There are some best practices I feel people should be using as they're deploying EV SSL certificates but really it still kind of a moot point until the browsers can come up with a solution,” he says. “Unfortunately, it’s not an easy fix for them. It’s not something that can be rolled out with the next monthly patch.”

[jnever1]

from Wildcard certificate spoofs web authentication • The Register

Black Hat In a blow to one of the net's most widely used authentication technologies, a researcher has devised a simple way to spoof SSL certificates used to secure websites, virtual private networks, and email servers.

The attack, unveiled Wednesday at the Black Hat security conference in Las Vegas, exploits a weakness in the process for generating secure sockets layer certificates. It works by adding a null string character to several certificate fields, a technique that tricks browsers and other SSL-enabled programs into misinterpreting the domain name that is being authenticated.

Security researcher Moxie Marlinspike created what he called a universal wildcard certificate that in many ways resembles certificate authority certificates that VeriSign and other companies use to generate SSL certificates. He did it by applying for a normal certificate for his website thoughtcrime.org. In the commonName field he listed the site as *\0.thoughtcrime.org, giving him a certificate that tricks many programs into authenticating virtually every address on the internet.

"You get this certificate and it will match any domain you're trying to connect to," Marlinspike told the Black Hat audience. "It's actually better than a CA cert because if you get a CA cert you at least have to create and sign another certificate to then present it for whatever you're trying to connect to. This you just hand them over and over again. You don't need to sign anything."

The attack came the same day that fellow researchers Dan Kaminsky and Len Sassaman laid out some half-dozen vulnerabilities in X.509, the technology that implements the PKI, or public key infrastructure that makes the SSL system work. Coincidentally, one of their attacks involved the same null-termination technique laid out by Marlinspike.

Another exploit targeted a decade-old VeriSign root certificate that was signed using MD2, an algorithm that's vulnerable to what's known as preimage attacks, in which someone is able to find a message that generates a predetermined hash.

"What we see is a real crisis in authentication," Kaminsky said during a press conference following his talk. "PKI was supposed to fix all this. We've been trying to do this for 10 years, and it's just not working."

Kaminsky said the current PKI system should be overhauled and rolled into DNSSEC, a security standard that's being implemented to better secure the domain name system.

The research isn't particularly comforting for people who regularly depend on SSL to authenticate websites and encrypt sensitive transactions.

Marlinspike has updated a software tool he wrote called SSLSniff to take advantage of the null-termination SSL bug. It allows a computer plugged into a network to all other network users to receive spoofed SSL pages that look identical to the real thing. The computer then logs all incoming and outgoing traffic that normally would have traveled through encrypted channels.

SSLSniff can also be used to automatically exploit software update mechanisms that rely on SSL for authentication. Instead of installing the update, the software pushes a malware package of the attacker's choice.

At the moment, version 3.5 of Firefox is the only browser that is protected against the attack, although Sassaman said Internet Explorer provides some protection too. ®

[jnever1]

In other words, Palm didn't "fix" this on the webkit end. They turned it off entirely.

I'm sure they did so in order to ensure that they 'have taken reasonable measures to prevent any such unauthorized authentication spoofing'

I don't blame them. Would you want to be the vulnerable browser that allowed personal info to be snooped?

My efforts are to get this re-enabled, while enjoying the benefits of the 1.3.1 upgrade. So far all I've hit are brick walls. Palm's version of webkit isn't open source (webkit , unaltered, is the open source project behind apples Safari browser) Remember, the entire WebOS is essentially a browser (kinda like the windows and iexplorer in MSWindows are an effectualization of MSexplorer). Anyway, to reverse engineer palm's webkit browser-app, I would need a decompiler, coding knowledge beyond your backyard SQL driven web application, and some sort of map to get me to the meat and potatos of this flaw-gone-wild.

I was hoping that the map would be readily producible upon fault logging of browser-app, but I don't know how to enable this feature (or even if it exists).

I'm not giving up though.
Palm offers certail packages in WebOS as open source, found here:
opensource.palm.com - WebOS1.3.1
and here:
opensource.palm.com - WebOS1.2.1

The entire OS can be downloaded in WebOSDoctor form as .jar files (which can be browsed as archives using 7-zip) from the wiki, here:webos doctor .jar files

All the research can be done without actually effing with your pre.
Get the SDK and emulator running, and I 'suppose' you could testbench, but the reality is that any fix would need be tested on a live device in a live situation.

My situation is 20 miles away and I only visit it twice a week.

Anyway... I'm momentarily burned on this because I managed to de-tap my screen (what good is a touch screen if touching it doesn't work!) from either all the screwing around with WinSCP and SFTP and SSH (not likely) or some unfavorable combination of patches, 'dangerous' or not.

Good luck if you need it. Help out if you can.

[jnever1]

found in webkit-patch inside of the webkit-patch.gz file on opensource.palm.com 1.3.1 opensource packages page:

+/** @defgroup CURL libcurl errors
+ * Errors returned by the CURL library (libcurl).
+ * /usr/include/curl/curl.h


+const int ERR_CURL_SSL_CONNECT_ERROR = 2035; ///< CURLE_SSL_CONNECT_ERROR(35)
+const int ERR_CURL_PEER_FAILED_VERIFICATION = 2051; ///< CURLE_PEER_FAILED_VERIFICATION(51)

from : http://curl.haxx.se/libcurl/c/libcurl-errors.html

CURLE_PEER_FAILED_VERIFICATION (51)

The remote server's SSL certificate or SSH md5 fingerprint was deemed not OK

[jnever1]

from : webkit-v8-patch in webkit-v8-patch.gz as downloaded from opensource.palm.com - 1.3.1

- // *begin* IMPORTANT SSL !!!!!
-
- // NOTE : This skips the cert verification step, allowing Man-in-the-middle attacks. We
- // are enabling this for now to get SSL (HTTPS) working, but we need to fix this before ship.
- curl_easy_setopt(m_handle, CURLOPT_SSL_VERIFYPEER, 0);
- curl_easy_setopt(m_handle, CURLOPT_SSL_VERIFYHOST, 0);
-
- // *end* IMPORTANT SSL !!!!!

looks like this is what I've been looking for

from curl.haxx.se

1. Tell libcurl to *not* verify the peer. With libcurl you disable this with
curl_easy_setopt(curl, CURLOPT_SSL_VERIFYPEER, FALSE);

With the curl command line tool, you disable this with -k/--insecure.

unfortunately, this doesn't seem to be working at the command line and the -k/--insecure returns option -k/--insecure: is unknown at the bash prompt even though it is clearly an curl option (type curl --help and you'll see it.

I'm going to try to upload curl's latest cacert.pem to my palm to see if THAT works, probably won't. More likely I'm going to have to recompile/install curl and libcurl without ssl support.

[samkim]

Originally Posted by jnever1

unfortunately, this doesn't seem to be working at the command line and the -k/--insecure returns option -k/--insecure: is unknown at the bash prompt even though it is clearly an curl option (type curl --help and you'll see it.

That means, use -k OR --insecure...

[glorifiedg]

I don't any linux knowledge so... i can't really help! :S

The strangest thing is that this error doesn't pop when I use the emulator...

[jnever1]

Originally Posted by samkim

That means, use -k OR --insecure...

Yeah... i tried all three. it's not a config switch, it's an argument modifyier. without an immediate web address to append, curl is not going to help my cause. It can, however, help narrow the scope of possible roadblocks (which I have down to curl itself or libcurl).

the big issue with the curl --insecure is that i would have to command line into my school... that is a no go. I don't want to browse the web entirely in HTML spit out on a terminal screen.

EDIT

As a test, I did the following with success:
1. ) wi-fi on (got a new pre today! to replace my tap dead unit) : connected to school (given IP etc)
2.) opened browser (clicked amazon icon just to trigger school redirect)
3.) recorded https address of Error 2051 (my attempt to break this issue with new certs failed again, expectedly)
4.) opened Terminal homebrew
5.)

curl -k https://***.***.edu/auth/...

(it doesn't look like this, but I'm not going to plaster this forum with private info ;-)
6.) Danced a little in my chair because i got in!!!

By "getting in", i mean that the HTML of the login page flooded my terminal screen. It was a muted success.

The positive outcome is that I know, now, libcurl needs to be recompiled/reinstalled without ssl authentication support.

That said, to any who would do the same as me: be warned that disabling ssl verification might leave your sensitive data wide open for viewing, if you hook up to a spoof site.

Furthermore, a warning: This recompile would NOT fix the recently discovered ssl vulnerability, in fact, it would amplify it. However, ssl-ing into a TRUSTED network over a TRUSTED connection should make you no less open to attack than with the verification left as comes 1.3.1.

[greenoyster]

Have you tried manually adding the certificate using the Certificate Manager?

[glorifiedg]

Sorry for my ignorance: there is a simple solution?