j2objc doest support javax.net.ssl.HttpsURLConnection

[chiky...@gmail.com]

HttpsURLConnection cannot be resolved when compile with j2objc. It seem j2objc currently doesn't support javax.net.ssl. Any plan in future? Will it support in j2objc?

[Tom Ball]

Yes, we plan on supporting javax.net in a quarter or two. What's blocking it are java.security providers for crypto, certificates, key signing and factories, secure sockets, etc. To avoid creating any new security vulnerabilities, these providers need to be carefully integrated with the iOS Security Framework, then reviewed by Google's security team (who reviewed and approved the secure hash and secure random providers we have). With full crypto implemented, we'll be able to support javax.net.ssl using OkHttp, like Android does.

On Mon Oct 13 2014 at 11:57:21 PM <chiky...@gmail.com> wrote:

HttpsURLConnection cannot be resolved when compile with j2objc. It seem j2objc currently doesn't support javax.net.ssl. Any plan in future? Will it support in j2objc?

--
You received this message because you are subscribed to the Google Groups "j2objc-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to j2objc-discuss+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Tom Ball]

FWIW, we currently support HTTPS URLs using HttpURLConnection, you just can't cast the result to HttpsURLConnection. 

[chiky...@gmail.com]

> To unsubscribe from this group and stop receiving emails from it, send an email to j2objc-discus...@googlegroups.com.

>
> For more options, visit https://groups.google.com/d/optout.

Thanks Tom for the info.

[G]

Hi Tom,
5 months have passed since your answer. Is there any update about the schedule for SSL support?

> To unsubscribe from this group and stop receiving emails from it, send an email to j2objc-discus...@googlegroups.com.

[Tom Ball]

Still working on security providers. URLConnection still accepts HTTPS URLs until then.

To unsubscribe from this group and stop receiving emails from it, send an email to j2objc-discuss+unsubscribe@googlegroups.com.

[Tom Ball]

I'm sorry this is taking so long, but we're just a two-person team juggling lots of priorities. Our top-priorities remain quality and performance, so there will always be bug fixes and code improvements over expanding the JRE support. That said, SSL support is one of the remaining features blocking us from doing a 1.0 release, since it's considered necessary functionality.

[gilad...@gmail.com]

Of course, keep up the good work, it's a wonderful project.

By the way, what does it mean using URLConnection with HTTPS URLs? What will be the behavior?
1. Is it just going to ignore SSL and use plain HTTP (sounds unreasonable since the server might not support plain HTTP and anyhow it will be a complete mess security-wise, since the developer will expect an encrypted connection)?
2. Is it going to be encrypted but the server certificate won't be validated?
3. Will SSL work as expected, but the code just won't have access to the extended HttpsURLConnection interface (so for example, can't check which cipher is used)?

[Tom Ball]

#3 -- a secure connection without extended API support. Currently, HttpURLConnection is implemented by IosHttpURLConnection, which delegates to the iOS NSURLConnection. This iOS class fully supports HTTPS (or iPhones would be much less useful :-), but doesn't surface the level of control needed to support the HttpsURLConnection extensions.

One option to address is to use NSURLSession, but it too isn't as fully featured enough to support every lever that java.net and javax.net.ssl make public, and we've found that anything less than full support of all obscure functionality winds up excluding some useful Java libraries. So instead, the current plan is to follow Android's lead and include Square's okhttp in jre_lib, pass its extensive test suite (it helps ex-Googlers wrote it, as we're a little test-obsessed), then add the Android SSL support that's based on okhttp. 

What's been blocking that is that okhttp understandably relies on java.security providers. Our app teams made it quite clear they don't want a separate security mechanism (like adding Bouncy Castle), because iOS apps need to work with the device's existing security support. So I've been slowly learning how to implement a java.security provider correctly with providers that directly use the iOS Security Framework. Now that the java.security API is in place, the focus will be on providing just the security support okhttp needs and iOS already provides, rather than everything java.security provides. So, for example, iOS doesn't support DSA and okhttp doesn't need it, so requesting a DSAKeyFactory will fail.

Hopefully this explains our strategy, and is a reasonable excuse for its delay. My thought is that late security support is better than early insecurity, even if frustrating to our clients.

To unsubscribe from this group and stop receiving emails from it, send an email to j2objc-discuss+unsubscribe@googlegroups.com.

[gilad...@gmail.com]

It does explain. Many thanks for the detailed answer and the great work.

[G]

On Saturday, March 7, 2015 at 6:35:34 PM UTC+2, Tom Ball wrote:

> I'm sorry this is taking so long, but we're just a two-person team juggling lots of priorities. Our top-priorities remain quality and performance, so there will always be bug fixes and code improvements over expanding the JRE support. That said, SSL support is one of the remaining features blocking us from doing a 1.0 release, since it's considered necessary functionality.
>
>
> On Sat, Mar 7, 2015 at 7:02 AM Tom Ball <tb...@google.com> wrote:
>
> Still working on security providers. URLConnection still accepts HTTPS URLs until then.
>
>
> On Sat, Mar 7, 2015 at 12:58 AM G <gilad...@gmail.com> wrote:
> Hi Tom,
>
> 5 months have passed since your answer. Is there any update about the schedule for SSL support?
>
>
>
> On Tuesday, October 14, 2014 at 5:37:01 PM UTC+3, Tom Ball wrote:
>
> > Yes, we plan on supporting javax.net in a quarter or two. What's blocking it are java.security providers for crypto, certificates, key signing and factories, secure sockets, etc. To avoid creating any new security vulnerabilities, these providers need to be carefully integrated with the iOS Security Framework, then reviewed by Google's security team (who reviewed and approved the secure hash and secure random providers we have). With full crypto implemented, we'll be able to support javax.net.ssl using OkHttp, like Android does.
>
> >
>
> >
>
> > On Mon Oct 13 2014 at 11:57:21 PM <chiky...@gmail.com> wrote:
>
> > HttpsURLConnection cannot be resolved when compile with j2objc. It seem j2objc currently doesn't support javax.net.ssl. Any plan in future? Will it support in j2objc?
>
> >
>
> >
>
> >
>
> > --
>
> >
>
> > You received this message because you are subscribed to the Google Groups "j2objc-discuss" group.
>
> >
>
> > To unsubscribe from this group and stop receiving emails from it, send an email to j2objc-discus...@googlegroups.com.
>
> >
>

Hi Tom,
I'm following your great work in GitHub and am excited about the progress that has been made.
I wanted to check out if there's anything new regarding SSL.
More specifically, we need support for SSLSocket and the like (as opposed to HttpsUrlConnection, which you can workaround using HttpUrlConnection and https URLs). If support for SSLSocket won't be soon, can you think about a suitable workaround?

[Bruno]

Hi Tom,

Thanks for your insights on this. Now that 0.9.8 is out the door, can you give us an update on this? Is it realistic to have this for the 1.0 release? I've been talking with someone at Square and they're going to be trying out J2ObjC and potentially our Gradle Plugin as well. I think there's a very interesting place where we could bring together J2ObjC, okhttp, QUIC, GRPC and Proto3. There's still a lot of elements that need to be worked out but I'm thinking of organizing a get together to help those parties collaborate.

Bruno

[jsh...@gmail.com]

Hi Tom. Thank you for the great work you have done on this project. Will your planned support of java.security providers extend to SSLContext and SSLEngine? I realize this is one level deeper than perhaps what OkHttp uses.

(Sorry for the formatting of the msg if it is ugly. First time posting here.)

[Tom Ball]

No, the current plan is to stop at OkHttp support. Developers needing a finer-grained security model should really work directly with the native security APIs, as our small team does not have the resources to provide the level of security testing a full API requires. OkHttp support is really stretching us to our limits. :-)

[in...@uppersetting.com]

Tom thanks for the great work on this project. I am desperately in need of SSL support at this point in my project. I was hoping you have an update?

Thanks
Michael Janulaitis

> To unsubscribe from this group and stop receiving emails from it, send an email to j2objc-discus...@googlegroups.com.

[Tom Ball]

j2objc supports HTTPS URLs. Since it uses NSURLConnection, iOS handles the SSL support correctly.

[Christopher Brind]

Is certificate pinning support there yet?

Thanks,
Chris


On 2 October 2015 at 18:32, 'Tom Ball' via j2objc-discuss

[in...@uppersetting.com]

I'm not using HTTP, straight sockets. I need X509TrustManager support so my client/server application framework can communicate over SSL/TLS 1.2. Any chance that is going to get added?

[Nick]

I too am very interested in this topic, particularly with regard to cert pinning.  We have an app that has all of the http client code in Java and would love to avoid stubbing the core http communication stuff if possible.

So two part question I guess:
1 - is there currently a strategy I can use to accomplish this today that doesn't require separate http client implementations for both iOS and Android? (abstracting just the pinning logic would be fine though)
2 - if not, is it realistic to expect one to be available in the future?

Thanks!

[Tom Ball]

1. There are no alternatives I've aware of with the j2objc distribution, but perhaps other developers have solutions.

2. We cannot commit to any date, or even to ever fully supporting all secure networking options that the Java runtime supports. Our plan is to work on porting networking libraries like OkHttp and google-http-java-client, adding only the functionality those libraries need, so app developers have some options. That will require certificate and key management support, and with that, we can provide some crypto support. We'll never provide 100% JRE compatibility, though, since that's never been the project's goal; it's always been a means to share business logic between app platforms.

The reason more apps aren't blocked by this is because in most cases, they only need a small subset of all Java security features, and so writing a screen or two of native code for iOS isn't the burden it initially seemed. iOS has a relatively easy-to-use Security Framework, and StackOverflow has lots of supportive iOS developers happy to help with problems. Any engineer who understands their app's security issues well enough to write secure, correct Java code for them can do the same more quickly in Objective C (since rewriting an already solved problem is almost always faster). Don't wait, especially as your solution may wind up working better for your app that anything we may provide in the future!

--

[Nick]

Thanks for the reply Tom!  The security code definitely seems pretty straightforward, but as I understand it, this would also require that we abstract the http client pieces to be implemented by each platform as well, is the real piece we'd like to avoid.

Early on we actually did have this abstraction in place but ran into some issues when Apple deprecated the async communication method we were using. We managed our own networking threadpool in the shared code to keep everything on the background and had each client implement a simple synchronous request method.  Seems apple decided devs are too dumb to do that on their own :(  Also had some trouble with the way certain http 4xx codes automatically trigger an exception and seemingly throw away the response body, which for us contained json data we required on the client.  Undoubtedly there's ways to overcome both of those things, but our problems disappeared  (implementation got much lighter too) when we moved the networking stuff into the shared code.  Maybe you could suggest an alternative to NSURLSession that I could try?

[Tom Ball]

Unfortunately, I'm not aware of any good NSURLSession alternatives (being a languages/compiler guy, I have always depended on the kindness of (security and networking) strangers :-). However, every time I've posted iOS questions on StackOverflow, the responses have been very helpful. Questions that include j2objc specifics don't get good answers, though, since it's more specialized. Your best chance is to post "pure iOS" questions, and we'd love it if you share any gems you find.

On Fri, May 20, 2016 at 8:32 AM Nick <ni...@awoona.com> wrote:

Thanks for the reply Tom!  The security code definitely seems pretty straightforward, but as I understand it, this would also require that we abstract the http client pieces to be implemented by each platform as well, is the real piece we'd like to avoid.

Early on we actually did have this abstraction in place but ran into some issues when Apple deprecated the async communication method we were using. We managed our own networking threadpool in the shared code to keep everything on the background and had each client implement a simple synchronous request method.  Seems apple decided devs are too dumb to do that on their own :(  Also had some trouble with the way certain http 4xx codes automatically trigger an exception and seemingly throw away the response body, which for us contained json data we required on the client.  Undoubtedly there's ways to overcome both of those things, but our problems disappeared  (implementation got much lighter too) when we moved the networking stuff into the shared code.  Maybe you could suggest an alternative to NSURLSession that I could try?

--

[gawade...@gmail.com]

Hi Tom,
Need your help with Http post request using j2objc. I have a java class which makes Post request to our server, which I have converted it to Objc classes using Eclipse plugin. I trying to make a Post request to server through Objc classes which gives me following error-

Https support is unavailable. Fix this by:
1) If linking with -ObjC, add -ljre_ssl to the link flags.
2) If linking without -ObjC, call JavaxNetSslHttpsURLConnection_class_() to create a compile-time dependency.'

However I added "-ljre_ssl" to Other Linker Flags but still gives out the same issues.
Requesting your help for the same.

Regards,
Gitesh

[Tom Ball]

Find the link step for your app in the build log. Check its flags to make sure the -ObjC flag and the -ljre_emul (or -l jre_emul) flags are specified. (Once you have a working build, you instead link with the JRE subset libraries like jre_ssl).

My guess is that you specified “-I” (capital i) instead of “-l” (lowercase L). It’s easy to make that mistake since they look so similar (the same on my iPhone). You won’t get a bad flag error with that typo since dash-capital-i is a valid compiler flag that is ignored when linking.

[Gitesh]

Hi Tom, 

Thanks for the prompt reply. As suggested by you, I was missing -ObjC flag. 

Also, I replaced "-ljre_ssl" with "-l z" flag, because it first gave out Undefined Symbols for architecture armv7 compile time error. On referring the "Required Linked Settings"  section of j2objc guide, I found that I need to added "-l z" flag to Other Linker Flag. But again it threw Compile time error of duplicate symbols which was resolved by simply removing "-ljre_ssl" and now the final value for Other Linker flags is "-l jre_emul -liconv -ObjC -l z"

Thanking you once again !! Cheers :)  

[BhavdipB]

I am also facing same issue  what @Gitesh was facing before.

but after doing same changes in code I am not resolving duplicate symbol issue

My Other linker is - -l jre_emul -liconv -ObjC -l z

Also My config file contains  - J2OBJC_HOME = /Users/xxxxxxxxxxx/Downloads/j2objc-2.1.1;

I think I am having issue with architecture x86_64

Please help me for this

duplicate symbol _JavaLangReflectMethod_class_ in:

    /Users/sameerskycore/Downloads/j2objc-2.1.1/lib/libjre_emul.a(Method.o)

    /Users/sameerskycore/Downloads/j2objc-2.1.1/frameworks/JRE.framework/JRE(Method.o)

ld: 26040 duplicate symbols for architecture x86_64

clang: error: linker command failed with exit code 1 (use -v to see invocation)

[BhavdipB]

I did this with removing Link Binary with LIbraries except `security.framework`

[Tom Ball]

So your link errors are fixed? It’s important to remember that jre_emul contains all of the JRE classes, of which the other jre_* libraries are subsets. So either link with subsets to reduce your app size or only use jre_emul, but never combine them since that will always cause duplicated symbol errors.

It’s therefore recommended that you always start with jre_emul (since the app’s JRE dependencies may change), and only switch to subsets if app size is an issue when you are ready to deploy your app.

[Bhavdip Bhalodia]

So I think that is the issue when I added both subsets and JER classes.

And that was returning me duplicate symbols issue.

By the ways thanks for making Great job :)

Cheers :)

To unsubscribe from this group and stop receiving emails from it, send an email to j2objc-discuss+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "j2objc-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to j2objc-discuss+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Thanks & Regards,
Bhavdip Bhalodia

+91 9033419936 / 9035550343

-- naa tvaya vina --

[Bhavdip Bhalodia]

Hi Tom, 

I need one more help from your team.

I am working with network calls using Https

But I am facing error with these variables

Showing All Messages
  symbol:   class HttpClient
Showing All Messages
error: PATH_TO_MY_ENGINE/MyEngine.java:67: cannot find symbol

Also getting same error in below also

 HttpClient, HttpPost, StringEntity, HttpResponse

Does I have to add library to my class or add anything else to my code like link flag ...

Please help me on this.

On Wed, May 2, 2018 at 8:17 PM, Bhavdip Bhalodia <bhalodia...@gmail.com> wrote:

So I think that is the issue when I added both subsets and JER classes.

And that was returning me duplicate symbols issue.

By the ways thanks for making Great job :)

Cheers :)

[Tom Ball]

None of those classes are in any library included in the j2objc distribution. My guess is these are all from Apache HttpCore, which you may be specifying on your j2objc command's -classpath argument. Every library you specify on the classpath must be separately translated, and included when linking. There's no magic -- the iOS linker cannot link in jar files to resolve external dependencies.

One way to include all dependent classes without necessarily including whole libraries is to specify all dependent libraries using the -sourcepath argument (not the -classpath), and then add the --build-closure flag. This tells j2objc to build every source file you explicitly specify, and also every dependent class those sources depend on (plus the sources the dependencies depend on, and so on). If that step fails because of a missing class, find the library it's in, add its source jar to the source path and try again. 

Some developers find this process easier to do this using javac, a source path (no class path), and a list of app files. It's the same process, since j2objc uses javac as its front end, so all missing class errors were reported by javac anyway. But for some reason, some developers see "javac error ..." and think "that's something I should fix", but see "j2objc error ..." and assume j2objc is broken. Maybe Oracle does a better job setting expectations than we do. :-)

Here's an even easier tip: don't use HTTPS or SSL, instead use URL.openConnection() with HTTPS URLs. If all your app needs is a solid way to transfer data to and from a server using HTTPS, URLConnection works great because it uses the iOS NSURLSession built-in class. Some Java apps and libraries use complex SSL code because years ago that was the only way to do so, but it's all built-in in iOS. Here's a simple example, which returns the text from https://j2objc.org/:

import java.net.URL;

import java.io.*;

import javax.net.ssl.HttpsURLConnection;

public class JavaHttpsExample {

  public static void main(String[] args) throws Exception {

    String httpsURL = "https://j2objc.org/";

    URL myUrl = new URL(httpsURL);

    HttpsURLConnection conn = (HttpsURLConnection)myUrl.openConnection();

    InputStream is = conn.getInputStream();

    InputStreamReader isr = new InputStreamReader(is);

    BufferedReader br = new BufferedReader(isr);

    String inputLine;

    while ((inputLine = br.readLine()) != null) {

      System.out.println(inputLine);

    }

    br.close();

  }

}

On Wed, May 2, 2018 at 12:06 PM Bhavdip Bhalodia <bhalodia...@gmail.com> wrote:

Hi Tom, 

I need one more help from your team.

I am working with network calls using Https

But I am facing error with these variables

Showing All Messages
  symbol:   class HttpClient
Showing All Messages
error: PATH_TO_MY_ENGINE/MyEngine.java:67: cannot find symbol

Also getting same error in below also

 HttpClient, HttpPost, StringEntity, HttpResponse

Does I have to add library to my class or add anything else to my code like link flag ...

Please help me on this.

On Wed, May 2, 2018 at 8:17 PM, Bhavdip Bhalodia <bhalodia...@gmail.com> wrote:

So I think that is the issue when I added both subsets and JER classes.

And that was returning me duplicate symbols issue.

By the ways thanks for making Great job :)

Cheers :)

--

Thanks & Regards,
Bhavdip Bhalodia

+91 9033419936 / 9035550343

-- naa tvaya vina --

--

Thanks & Regards,
Bhavdip Bhalodia

+91 9033419936 / 9035550343

-- naa tvaya vina --