Using VBScript, want to talk to a HTTPS website but it fails with:
The client and server cannot
communicate, because they do not
possess a common algorithm
Found out this is because it needs to use SSL3. How can I tell it to use SSL v3?
Thanks
ServerXmlHTTP relies on WinHTTP, which supports SSLv3. See the WINHTTP_FLAG_SECURE_PROTOCOL_SSL3 in the documentation. What version of MSXML are you using? You may want to try using one of the later versions. See the documentation on ProgID information.
Related
I am running Hazelcast as a cache service, it seems I can improve perf with BoringSSL and this is simpler because I don't need to install additional software
Reading their doc: https://docs.hazelcast.com/imdg/4.1.2/security/integrating-openssl.html
I see that I just need two jars, but I don't see any mention of config settings. Do I just use the Java SSL settings with BasicSSLContextFactory?
I see I can use com.hazelcast.nio.ssl.BasicSSLContextFactory as mentioned here https://docs.hazelcast.com/imdg/4.1.2/security/tls-ssl.html#tlsssl-for-hazelcast-members for the Java SSL implementation
They also provide com.hazelcast.nio.ssl.OpenSSLEngineFactory for OpenSSL integration (https://docs.hazelcast.com/imdg/4.1.2/security/integrating-openssl.html#using-openssl)
BoringSSL is the library to use OpenSSL. So this link is a good source. However, if you not bound to the old Java versions, then nowadays Java TLS is faster than OpenSSL, so no need for BoringSSL.
Since SSL is a Hazelcast Enterprise feature, feel free to raise a Hazelcast Zendesk Ticket if you need some more detailed help.
Starting with Hazelcast version 4.0, there is the following logic deciding which TLS engine is used:
when Java version<11 and a netty-tcnative package (wrapping OpenSSL, BoringSSL, ...) is on the classpath: Use the OpenSSLEngineFactory;
in all other cases: Use the BasicSSLContextFactory.
Surely, you don't need to use the defaults, but you can specify the factory-class-name configuration attribute with the factory of your choice.
You can use the same properties in OpenSSLEngineFactory like the ones in BasicSSLContextFactory (e.g. keyStore*, trustStore*). Nevertheless, the native way of configuring the OpenSSLEngineFactory is by using keyFile and other properties mentioned in the documentation section about OpenSSL.
Why the Java 11 check
As mentioned above, the OpenSSLEngineFactory is not used for Java 11 and newer by default. This decision was based on Hazelcast performance testing which shows OpenSSL performance benefits when used with Java 8, but not with Java 11 (or newer).
Here are throughput graphs from those tests (performed in 2019).
TLSv1.2
TLSv1.3
I need to connect a WinCE6.0 device to a web based server using HTTPS.
The problem: WinCE6.0 uses WinInet v6 which supports SSL2, SSL3 and TSL1.0 None of which are supported in the current (2018) best practices due to their security flaws.
I doubt I can drop in a newer version of WinInet and expect it to run.
I had thoughts of porting CURL to WinCE.
I'm thinking this issue has already been addressed by the CE community, but I'm not seeing an available solution.
How can I get an old embedded device to securely connect to the WWW?
From GuruCE:
If you want to use TLS 1.1 and 1.2 on CE a suitable solution is to use mbedTLS library from ARM. It has a BSD-like license, so not too restrictive. Only one change to the makefiles is needed to get it to work on CE.
Is there a common data interface for RavenDB? For example, how could Java, Python, or even PHP interact with RavenDB?
In RavenDB 3.0 they added a Java client as well. I haven't tried it myself, but you can read about it here:
http://ayende.com/blog/168354/what-is-new-in-ravendb-3-0-jvm-client-api
In that blog post Ayende also mentions:
RavenDB has always been accessible from other platforms. We have users using RavenDB from Python and Node.JS, we also have users using Ruby & PHP, although there isn’t a publicly available resource for that.
With RavenDB 3.0, we release an official Java Client API for RavenDB. Using it is pretty simple if you are familiar with the RavenDB API or the Hibernate API.
So to answer your question: No, there isn't a "common data interface" for everything, but most things are certainly doable.
Almost every ravendb command is available through HTTP via REST.
For version 2.5 it is documented http://ravendb.net/docs/article-page/2.5/csharp/http-api/http-api-single. For version 3 they ommitted that documentation (or it is not available yet), but it is still there.
The client (.net or java) is 'just' a wrapper around those HTTP REST calls that does things like caching, serializing, failover, etc..., to make it much easier to work with RavenDB in your application.
I'm trying to add SNI to my client-side program (C/C++) that uses Microsoft SDK's Schannel API for TLS.
I've searched everywhere but could not find any documentation on how Schannel supports SNI extension.
I looked up the documentation for AcquireCredentialsHandle(), InitializeSecurityContext() but no success.
So, could anyone please help me with some example code?
The SNI is specified as part of the ClientHello, which is generated by InitializeSecurityContext(). Specficially, Schannel uses the 3rd parameter of that function for certificate validation, as well, as SNI; but not all versions of Windows support TLS extensions (which includes SNI).
TLS Extensions were first introduced in Internet Explorer 7 beta 3 on Windows Vista. Plus, even if your operating system supports it, TLS will likely be turned off, by default.
There is a working example on CodeProject that shows SNI from the client and server side.
This is my first question ever in Stack-Overflow!
I am beginner in JIRA. So I wanted to know if there is any stable platform to connect from Java to JIRA without using REST API?
Can I use native Java libraries or any other additional libraries to connect to JIRA?
Yup, atlassian created jira-rest-java-client but doesn't "formally" support it...but is open source...last update was 2014-10-09...so seems maintained.
There is also the SOAP services, which are deprecated but still supported in JIRA 6. They provide instructions on how to build a SOAP client. They'll be phased out, replaced by the REST endpoints, moving forward.