I am trying to access the 3rd party SOAP service(securedSOAPService) from IBM Worklight 6.1 application server through HTTP Adapter.
Following is the configuration of adapter.xml of HTTP Adapter,
<?xml version="1.0" encoding="UTF-8"?>
<wl:adapter xmlns:wl="http://www.worklight.com/integration" xmlns:http="http://www.worklight.com/integration/http" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" name="demoAdapter">
<displayName>demoAdapter</displayName>
<description />
<connectivity>
<connectionPolicy xsi:type="http:HTTPConnectionPolicyType">
<protocol>https</protocol>
<domain>mydomain.com</domain>
<port>8080</port>
</connectionPolicy>
<loadConstraints maxConcurrentConnectionsPerNode="2" />
</connectivity>
<procedure name="securedSOAPService" />
</wl:adapter>
Below are the observations:
The services returns "javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated" when service “securedSOAPService” is configured with TLS1.2.
When we change the service to use TLS1.0, it works fine.
I want to enable HTTP adapter to work when Service is configured on TLS1.2.
Note: SSL is not configured on Worklight server.
Finally we figured out a solution which will work for limited ciphers of newer protocols(i.e. TLSv1.1,TLSv1.2),
Updated JAVA to 1.7.0_80 (or higher).
Enabled the TLS 1.1 and TLS 1.2 support from Java configuration.
change the configuration of TLSv1.2 in server.xml (link)
Added configuration in jvm.options of TLSv1.2 to make connection with higher protocol.
Added third party library 'BouncyCastle' to enable DH keypair.
Alter configuration in java.security add entry for BouncyCastle.
Restart the server.
Note: This will work for limited ciphers only. Best practice would be to use a newer version of java.
Thanks a lot Mohammed Ashfaq for your help!
Related
I have a Blazor WASM Application that shall be hosted inside the Backend that is implemented using gRPC on ASP.NET with .NET 5.0. When I try to debug the WASM application and as soon as the debugging Browser starts I get this error:
fail: Microsoft.AspNetCore.Server.Kestrel[0]
HTTP/2 over TLS was not negotiated on an HTTP/2-only endpoint.
All development certificates are installed and trusted and the websocket connection is established using wss:// scheme. So from my point of view the TLS negotiation should succeed.
I already found out that I can workaround that to a certain point by changing the Kestrel endpoint settings to use Http1AndHttp2 the problem then becomes that the gRPC connection from the frontend to the backend fails because of the downgrade to Http/1.
So my question is: Is there any option to debug Blazot WASM when using an Http/2 server on the hosting site?
If this is not possible: Can I determine somehow that the gRPC endpoints get delivered using HTTP/2 and the debugging endpoints via HTTP/1.1?
Here are some tips for checking TLS negotiation limitation on Http/2:
TLS version 1.2 or later
Renegotiation disabled
Compression disabled
Minimum ephemeral key exchange sizes:
Elliptic curve Diffie-Hellman (ECDHE) [RFC4492]: 224 bits minimum
Finite field Diffie-Hellman (DHE) [TLS12]: 2048 bits minimum
Cipher suite not prohibited.
So the solution is quitq simple: I used the wrong package. When using Blazor with gRPC the Grpc.Client.Net.Web package must be used (as stated in this article: https://learn.microsoft.com/en-us/aspnet/core/grpc/browser?view=aspnetcore-6.0#configure-grpc-web-with-the-net-grpc-client).
Then you do not have to use HTTP/2 and everything works like a charm.
I have an ASP.NET application that uses the DocumentDB .NET SDK (latest version v 1.10).
I am using the new local emulator.
When the app is started locally, I am not able to see the requests made by my .NET SDK to local emulator in Fiddler. However, I can see in Fiddler the requests to local emulator made by the web application "Data explorer" (shipped with Local emulator) in my browser. I can also browse in Fiddler DocumentDB requests from my locally deployed web app on a remote DocumentDB endpoint (in Azure).
I suspect there is some configs to be set in .NET SDK so that requests are intercepted by Fiddler proxy.
We finally managed to find a solution with two things to change:
In documentdb client instanciation set connectionPolicy.EnableEndpointDiscovery = false; (do not push this to production)
And replace the documentdb endpoint url from https://localhost:8081 to https://localhost.fiddler:8081
You can use fiddler to see the request and response if you choose Gateway or DirectHttps mode.
When you use .NET SDK, it will not automatically direct to the fiddler proxy so that you won't see your request/response automatically.
You can either set the proxy in your app config
<system.net>
<defaultProxy>
<proxy
usesystemdefault="False"
bypassonlocal="True"
proxyaddress="http://127.0.0.1:8888"/>
</defaultProxy>
</system.net>
Or you can use https://localhost.fiddler, which will go through fiddler proxy so that request/reponse is captured. Note this option will make request to fail if fiddler is NOT running.
Are you using Direct mode while connecting to the local emulator?
Fiddler will not be able to intercept requests when using direct connectivity since it can only intercept http traffic. Changing the connection policy to gateway should allow fiddler to intercept the requests.
I have a VB.NET 4.5 application on Windows Server 2008 R2 that must connect to one of our other internal applications on a Tomcat server via TLSv1.2. According to our security scans and server config (in preparation for PCI), we can only use these ciphers on that server:
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
I have generated the service class from the WSDL as usual, but a Wireshark capture doesn't list any of these ciphers as an option.
My questions:
What library does Microsoft.NET use behind the scenes for TLS connections? For example, does it still use SChannel?
Is there a way for me to enable / install new ciphers for VB.NET to use?
If it's using SChannel, maybe I can do some registry changes to get it working...? Or is it possible that these ciphers are just not available on Windows Server 2008 R2?
Thanks in advance!
.NET supports them but by default .NET TLS implementation is using only SSLv3/TLSv1 and it doesn't offer those ciphers.
To enable TLSv1.1 and TLSv1.2 (not sure which one actually enabled those ciphers) use:
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12;
This will enable TLSv1.1+ (and in process disables SSLv3) and .NET should start offering TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384.
Cheers
I am running JBoss with SSL, the certificate is generated with openssl:
<Connector protocol="HTTP/1.1" SSLEnabled="true"
port="8443" address="${jboss.bind.address}"
scheme="https" secure="true" clientAuth="false"
keystoreFile="${jboss.server.home.dir}/conf/chap8.keystore"
keystorePass="password" sslProtocol = "TLS" />
My client is an AIR application which interacts with the Java EE Server through GraniteDS. On the Flex/AIR side, I updated the channel to a SecureAMFChannel on services-config.xml:
<channel-definition id="myApp-graniteamf" class="mx.messaging.channels.SecureAMFChannel">
<endpoint uri="https://localhost:8443/myApp/graniteamf/amf"
class="flex.messaging.endpoints.SecureAMFEndpoint" />
</channel-definition>
Now, when I connect from my client, AIR asks me if I want to go ahead with the connection (view certificate, etc.).
I'm new to the whole SSL/HTTPS concept, but I've read some docs. What I'm trying to figure out now, is how to make my App know that a server is safe (localhost in this case). From what I got so far, the client application should "trust the server as a CA", or just trust the certificates from a certain server.
Can you give me some clues as to where to start to implement this on my AIR client side application?
If I understand correctly, you are using a self signed certificate. Going on that assumption you can't force a user to accept the certificate through your AIR app, that would be a security hole. To get a call from your AIR app to be trusted the user would need to import your certificate (or the untrusted CA you signed your certificate with) into their own keystore.
The way you do this is different for each OS, but an example of how to do it in Windows is to browse your server in IE, Get the cert warning, view the cert details and then export the cert to file (X509 iirc). Then you can right click the cert file and chose to install the certificate.
All subsequent calls to that secured server should then be trusted.
In our flex/air application we are calling a web service over https. The web service is java based and has, at the moment, an untrusted certificate.
When doing a POST to the service with some json, the payload on the server side is pretty garbled. A popup does occur asking whether you want to continue and even when I do and add the untrusted certificate into my keychain (on the mac), the data sent through always comes through mangled.
I installed charles http proxy to see the actual traffic and it seems at times I'm getting a SSLHandshakeException back... I'm guessing this is causing the garbled data as ssl isn't being setup properly.
So, to the question - can air/flex handle untrusted certificates? Is there a workaround that you can do? For example in java with commons httpclient you can work around it at the socket level.
Thanks,
Kieran
I don't know but it might help if you use the secure attribute in your server-side crossdomain.xml like this:
<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
<allow-access-from domain="mydomain.com" secure="false" />
</cross-domain-policy>