Your question is a bit confused (you state that "the connection between proxy and the application is encrypted using SSL" and then that "the connection between the application and proxy is NOT encrypted": apparently, you are using the term "application" to designate several distinct things).
That being said:
SSL is meant to be end-to-end. When the SSL client talks to the SSL server, they establish a tunnel which is safe from third parties (for confidentiality and integrity of data). This property holds even against whatever proxies the connection has gone through.
HTTPS (i.e. HTTP within SSL) can be forwarded through a proxy (see RFC 2817 sections 5.2 and 5.3).
An HTTP proxy is contacted through HTTP -- theoretically, it should be possible to contact it through HTTPS too, but browsers are not necessarily configurable that way. I have seen it done with a Proxy auto-config file which was returning the proxy not as an hostname+port pair, but as a full URL (beginning with https
), which is out of spec, but was working (I don't remember which browser supported that, though).
So you could make a SSL connection through a proxy, the tunnel between the application and the proxy being itself an SSL tunnel; at which point you would have two SSL tunnels, one nested in the other. But what would be the use ? If the data is sensitive enough to warrant SSL, then it should use SSL on the whole path, even beyond the proxy. And if it does use SSL for the whole path, then an SSL layer between application and proxy is superfluous.
(HTTPS with proxy makes sense when the proxy requires password-based authentication, and you fear interception of that password, though.)