any connection via http is redirected to https

[Jan-Marcek]

Currently, when a user tries to access odn via http://host then he is redirected (gets code 302) to https://host/. Some users have problem with https for example sparql loaders. They are unable to load data to virtuoso. Redirect is configured here: https://github.com/OpenDataNode/odn-box/blob/develop/apache/odn-simple-apache.conf#L55-L57

odn-box shall support both protocols http and https. The users can choose which one they want to use.

[ghost]

? which sparql loaders have problems? lets fix it...

i do not understand... in 21st century, https should be supported everywhere and there is no gain in turning it off... so lets fix places which do not support https.

On 08/11/2015 01:52 PM, Jan Marcek wrote:

Currently, when a user tries to access odn via http://host then he is redirected (gets code 302) to https://host/. Some users have problem with https for example sparql loaders. They are unable to load data to virtuoso. Redirect is configured here: https://github.com/OpenDataNode/odn-box/blob/develop/apache/odn-simple-apache.conf#L55-L57

odn-box shall support both protocols http and https. The users can choose which one they want to use.

— Reply to this email directly or view it on GitHub https://github.com/OpenDataNode/odn-box/issues/35.

[Jan-Marcek]

it was requested by @hanecak and @jindrichmynarz Please give us more details

[jindrichmynarz]

It is not a case for a DPU, but for LDVMi, another application bundled in ODN. If I understood it correctly, the problem is not with HTTPS per se, but that ODN does not have a valid HTTPS certificate. @jirihelmich is the main developer of LDVMi and he mentioned encountering this error:

ERROR: HttpException: javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated: Unexpected error making the query: javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated

ERROR: Unexpected error making the query: javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated

Maybe he can provide more details as to what HTTP client library is used etc.

[ghost]

Yes, certificate. If LDVMi is part of ODN, then Jan Marcek is able to install it with correct java Truststore. Since other components have to deal with this problem too. I know, that in Bratislava, they where playing around with truststores to get ODN https working.

On 08/12/2015 10:55 AM, Jindřich Mynarz wrote:

It is not a case for a DPU, but for LDVMi https://github.com/ldvm/LDVMi, another application bundled in ODN. If I understood it correctly, the problem is not with HTTPS per se, but that ODN does not have a valid HTTPS certificate. @jirihelmich https://github.com/jirihelmich is the main developer of LDVMi and he mentioned encountering this error:

|ERROR: HttpException: javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated: Unexpected error making the query: javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated

ERROR: Unexpected error making the query: javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated |

Maybe he can provide more details as to what HTTP client library is used etc.

— Reply to this email directly or view it on GitHub https://github.com/OpenDataNode/odn-box/issues/35#issuecomment-130221450.

[jirihelmich]

Query is fired by standard Jena implementation, Jena is creating the request.

[Jan-Marcek]

Full support of http is not possible, because cas doesn't supported it (from @peterklimo ) However, component as virtuoso, sparql, dumps, ic, pc and uv shall supported it.

[Jan-Marcek]

@jirihelmich Could you show code where is this request created please? Is there way how to tell Jena to don't do cert validation?

[jirihelmich]

A) To be constructive in scope of ODN: I use QueryExecutionFactory like this:

val execution = QueryExecutionFactory.sparqlService(endpoint,query)
val model = execution.execConstruct()
...

The actual usage is scattered into multiple files, but there is nothing more (in terms of Jena API) used.

HTTP request in Jena is implemented in http://grepcode.com/file/repo1.maven.org/maven2/com.hp.hpl.jena/arq/2.8.7/com/hp/hpl/jena/sparql/engine/http/QueryEngineHTTP.java#179

B) With all due respect, but to be absolutely honest, I don't know if I can tell Jena to ignore certificates and I'm not sure I should even try. If any other tool will try to communicate with ODN, it's author would need to go into code and downgrade the supported security level in order to work with "open" data? That's a really weird approach.

[ghost]

From what you posted, it seems Jena uses HttpUrlConnection (the Java plain one). We can try to configure truststore for jvm that run LDVMi: https://access.redhat.com/documentation/en-US/Fuse_MQ_Enterprise/7.1/html/Security_Guide/files/SSL-SysProps.html the

|javax.net.ssl.trustStore can specified to jvm:

java -D||javax.net.ssl.trustStore=/home/odn/our.trust.certs

|

[Jan-Marcek]

As far we don't provide LDVMI it is not possible to add cert to its tomcat trustStore. Just note, that this solution doesn't resolve the problem with external resources. those whose are in different host.

For now we support both protocols http and https with exception as I mentioned https://github.com/OpenDataNode/odn-box/issues/35#issuecomment-130558571 odn-cas doesn't support http.

[jirihelmich]

Moreover, there is no Tomcat with LDVMi, it's running on Play's built-in netty/Spray.

[ghost]

:D Jan-Marcek does not know the architecture of LDVMi :) Nor me. Nevertheless:

1. LDVMI has to act as https client: when dragging data from /sparql endpoint
2. LDVMI has to act as https server: when visualization is iframed in Dataset/Resource preview window in CKAN.

Lets start by not-mixing these two use cases. The former (1) is probably easy to solve by adding property (https://access.redhat.com/documentation/en-US/Fuse_MQ_Enterprise/7.1/html/Security_Guide/files/SSL-SysProps.html)

-Djavax.net.ssl.trustStore=/home/some/truststore/where/our/root/ca/cert/is/imported/the/one/which/signs/the/virtuoso/ssl/server/certificate/or/the/virtuoso/server/ssl/certificate/itself

as the certificate for https://odn/sparql is generated during installation of ODN, generating such truststore is also possible (keytool -importcert, see https://docs.oracle.com/javase/8/docs/technotes/tools/unix/keytool.html#keytool_option_importcert). and adding -D option to Java runtime which runs Play must be also possible somehow (although I do not know precisely, Play runs on java -> there must be some kind of start script).

The latter problem (2) is a little bit harder to solve as it has to be delivered by someone who knows ho to do Https application using Play framework or we have to study how to do it. I know, that our company have already developed one application using Play (in Kosice) in https mode. So it is POSSIBLE.

I am adding @hanecak keyword to draw his attention here.

[jirihelmich]

That's exactly why I'm telling you what the architecture is, to avoid misunderstandings. Not sure what is so funny about that, but never mind :)

Yes, it's possible, as everything is, for both cases you mentioned. I'm just pointing the fact, that the current certificate setup of ODN does not make sense out of the scope of ODN (which I thought should have been the main user group, since it's a platform for publishing data). Whoever wants to integrate it into the stack needs to deal with that.

But I have no inclination to pushing that code into the official LDVMi repo, since it supports a very bad, insecure and user un-friendly practice.

[hanecak]

Little excerpt/summing up from mail communication which happened recently, so as to not let this issue jast "hanging" without explanation:

ODN's design principle is "HTTPS everywhere", but:

• for private parts (ODN/InternalCatalog, ODN/UnifiedViews and ODN/midPoint) it is also enforced
• for public parts (ODN/PublicCatalog, public read-only SPARQL endpoint) it is optional, i.e. both HTTP and HTTPS have to work

HTTPS enforcement for private parts is needed because we need to protect authorization credentials used to access those parts.

Availability of both HTTP and HTTPS for public parts is needed because:

1. We do not want to force encryption on those who do not want it, we merely want provide it to those who actually do want it.
2. In cases when ODN is deployed with self-signed certificate, internal part is OK (ODN maintainer made the choice so he is also able to manage/help his users). But general public will have difficulties accessing ODN instance with such certificate and thus will thus usually opt for using HTTP.

Because of the 2nd point, the wild card redirect of all HTTP traffic to HTTPS - as persent on release 1.1.0 - is considered as bug and violation of design rules. That's why this issue was filled and should be fixed.

What @jirihelmich describe is one particular use-case when self-signed certificate on particular ODN instance (SAZP) is causing trouble for other particular application (LDVMi).

So, now in ODN 1.1.2 it is fixed but some further tweaks will be done in ODN 1.2.0 . See @Jan-Marcek 's comments above.

[hanecak]

Further elaboration regarding point 1 ( "We do not want to force encryption on those who do not want it, we merely want provide it to those who actually do want it." ): In this case we're dealing with anonymous access to open data. So in this case we are not protecting authentication credentials, we are mainly protecting user's privacy (i.e. information about what data he is accessing, etc.).

Inspiration can be found here:

https://https.cio.gov/

[jirihelmich]

Thanks for solving this a making it clear. Thu 27 Aug 2015 v 16:31 odesílatel Peter Hanecak notifications@github.com napsal:

Further elaboration regarding point 1 ( "We do not want to force encryption on those who do not want it, we merely want provide it to those who actually do want it." ): In this case we're dealing with anonymous access to open data. So in this case we are not protecting authentication credentials, we are mainly protecting user's privacy (i.e. information about what data he is accessing, etc.).

Inspiration can be found here:

https://https.cio.gov/

— Reply to this email directly or view it on GitHub https://github.com/OpenDataNode/odn-box/issues/35#issuecomment-135453238 .