SNI : SSLHandshakeException unrecognized_name - karate

I have the following error when trying to contact some website :
10:29:32.228 [ForkJoinPool-1-worker-1] ERROR com.intuit.karate - javax.net.ssl.SSLHandshakeException: Received fatal alert: unrecognized_name, http call failed after 35 milliseconds for URL: https://{redacted}
10:29:32.229 [ForkJoinPool-1-worker-1] ERROR com.intuit.karate - http request failed: javax.net.ssl.SSLHandshakeException: Received fatal alert: unrecognized_name
I have found the following answer : https://stackoverflow.com/a/14884941/10791639
I edited karate-apache/src/main/java/com/intuit/karate/http/apache/ApacheHttpClient.java L125, removing the comment from this line :
System.setProperty("jsse.enableSNIExtension", "false");
But I still have the same problem as before. I haven't found a public website that is requiring strict Server Name Indication to reproduce my problem.

We found a solution by changing something in karate-apache/src/main/java/com/intuit/karate/http/apache/ApacheHttpClient.java :
SSLConnectionSocketFactory socketFactory = new LenientSslConnectionSocketFactory(sslContext, new NoopHostnameVerifier());
becomes
SSLConnectionSocketFactory socketFactory = new SslConnectionSocketFactory(sslContext, new NoopHostnameVerifier());
#Peter, do you think a parameter to use strict or lenient SSL connection can be a possibility?

Related

Error in Postman: Error: write EPROTO 8768:error:1408F10B:SSL routines:ssl3_get_record:wrong version number:

During request GET in Postman (https://localhost:9001/test)
I've received an error:
Error: write EPROTO 8768:error:1408F10B:SSL routines:ssl3_get_record:wrong version number:c:\users\administrator\buildkite-agent\builds\pm-electron\postman\electron-release\vendor\node\deps\openssl\openssl\ssl\record\ssl3_record.c:252:
Warning: This request did not get sent completely and might not have all the required system headers.
Postman Configuration:
SSL certificate verification is disabled;
Proxy configuration - Default Proxy Configuration and Proxy configurations for sending requests are disabled;
Request timeout in ms - 0.
For Localhost we don't really need https, please try with http://localhost:9001/test
check that you are using the HTTP protocol not HTTPS to send requests to the server:
example
export const config = {
baseUrl: "http://localhost:4000"
}
it has to be the http not https for localhost
"http://localhost:3000"
NOT
"https://localhost:3000"
const transporter = nodemailer.createTransport({
host:'smtp.gmail.com',
port:587,
secure:false,
requireTLC:true,
auth: {
user:'youmail#gmail.com',
pass:'youpass'
}
}
Notice that secure: is false.
The error occurs when secure: is true.
the reason was in an incorrect link.
In the controller I have used
#RequestMapping(value="/{baseSiteId}/test")
And this {baseSiteId} was not what I expected.

enabling SSL for Hyperledger Fabric couchdb

I want to use couchDB(V. 2.3.1) with SSL enabled, so I added [ssl] part to /opt/couchdb/etc/local.d/docker.ini file as shown below:
[ssl]
port = 6984
enable = true
cert_file = /etc/hyperledger/fabric/tls/server.crt
key_file = /etc/hyperledger/fabric/tls/server.key
cacert_file = /etc/hyperledger/fabric/tls/ca.crt
[daemons]
httpsd = {couch_httpd, start_link, [https]}
[admins]
Admin = ...
[couchdb]
uuid = ...
but i can't access the webUI with https! having this error:
This site can’t provide a secure connection
"IP" uses an unsupported protocol.
ERR_SSL_VERSION_OR_CIPHER_MISMATCH
Unsupported protocol
The client and server don't support a common SSL protocol version or cipher suite.
this is the logs:
[error] 2020-05-17T06:52:18.046389Z nonode#nohost <0.19077.3> -------- SSL: hello: tls_handshake.erl:127:Fatal error: handshake failure - malformed_handshake_data
[error] 2020-05-17T06:52:18.046426Z nonode#nohost <0.18899.3> -------- application: mochiweb, "Accept failed error", "{error,{tls_alert,\"handshake failure\"}}"
[error] 2020-05-17T06:52:18.046508Z nonode#nohost <0.18899.3> -------- CRASH REPORT Process (<0.18899.3>) with 0 neighbors exited with reason: {error,accept_failed} at mochiweb_acceptor:init/4(line:75) <= proc_lib:init_p_do_apply/3(line:247); initial_call: {mochiweb_acceptor,init,['Argument__1','Argument__2',...]}, ancestors: [https,couch_secondary_services,couch_sup,<0.202.0>], messages: [], links: [<0.253.0>], dictionary: [], trap_exit: false, status: running, heap_size: 1598, stack_size: 27, reductions: 954
can somebody please help me?
I found the solution and wrote a post about it:
https://medium.com/#pouyashojaei85/enabling-ssl-for-docker-couchdb-container-127388eca1a8

C# JIRA Error Message: The request was aborted: Could not create SSL/TLS secure channel

When I run this it works and gives a valid reponse
private readonly Lazy<Jira> jiraClient = new Lazy<Jira>(() => Jira.CreateRestClient("https://jira...", "name", "pass"));
but when I try to run this I get an error.
Issue issue = await this.jiraClient.Value.Issues.GetIssueAsync(jiraId);
Error Message: The request was aborted: Could not create SSL/TLS secure channel
here is the answer
The request was aborted: Could not create SSL/TLS secure channel
ServicePointManager.Expect100Continue = true;
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

webpack dev-server: Avoid proxy errors on HTTP errors returned from proxy target

I have a Vue.js project where I have configured a webpack dev-server to proxy all requests to the UI to my backend server. Here is the relevant part of vue.config.js:
devServer: {
contentBase: PATHS.build,
port: 9000,
https: false,
hot: true,
progress: true,
inline: true,
watchContentBase: true,
proxy: {
'^/': {
target: 'http://127.0.0.1:8089',
secure: false
},
}
},
I've noticed that if the HTTP response code from http://127.0.0.1:8089 is anything other than 2xx then the proxy fails with the following error:
Proxy error: Could not proxy request /api/test from localhost:9000 to http://127.0.0.1:8089.
See https://nodejs.org/api/errors.html#errors_common_system_errors for more information (HPE_INVALID_CHUNK_SIZE).
This also causes the HTTP response code from the request to localhost:9000 to be 500 for any error and all the information about what went wrong on the server side is lost. This is problematic as I want to be able to extract information from error responses to display to the user.
I know it's possible to do because I had it working on an older Angular project which I think was using Webpack 3 (am now using Webpack 4). I tried copying all the dev-server config from this project but it just doesn't seem to work here!
EDIT: I was wrong. The Proxy error does not occur on every bad response but only for one of the requests which is a multipart file upload. Still unable to reproduce this in a smaller example to put on github though so struggling to pinpoint the cause.
This error message comes from node_modules/#vue/cli-service/lib/util/prepareProxy.js, which define a onError callback for node-http-proxy;
So I did some experiment, make back-end api generate 400 404 500 response, but I didn't got this error.
After I happen to close back-end api, error arise:
Proxy error: Could not proxy request /hello from localhost:8080 to http://localhost:8081 (ECONNREFUSED).
I search in the doc and find these:
The error event is emitted if the request to the target fail. We do not do any error handling of messages passed between client and proxy, and messages passed between proxy and target, so it is recommended that you listen on errors and handle them
So the onError do not handle error code, is called only when request fail (500 response is still treated as a complete request, connection refuse is not)
Go back to your error message, [HPE_INVALID_CHUNK_SIZE] means bad request to the back-end api. In this issue, it gives an solution: add a keep-alive header:
devServer: {
publicPath: 'http://localhost:9090/front/static-dev/build/',
port: 9090,
proxy: {
'/**': {
target: 'http://localhost:8080',
secure: false,
changeOrigin: true,
headers: {
Connection: 'keep-alive'
}
},
open: true
}
I have finally found the problem, and I apologise, it was a lot more of a specific issue than I originally thought when I wrote the question.
Issue was to do with a request which was proxied to another server using the Spring RestTemplate:
e.g.
#PostMapping("/upload")
public ResponseEntity upload(#RequestParam("file") MultipartFile file)
throws Exception {
String baseUrl = serviceProperties.getAddress();
HttpEntity<MultiValueMap<String, Object>> request = createMultipartRequest(file.getBytes());
return restTemplate.postForEntity(baseUrl + "/api/upload", filterRequest, String.class);
}
The ResponseEntity returning from the rest template proxy contained the header "Connection: close" when the response was anything other than 200 which cause the connection to close and caused this request to fail to return anything which subsequently made the dev-server proxy fail on the UI.
Fixed this by not passing the response headers from the rest template proxy to the response:
#PostMapping("/upload")
public ResponseEntity upload(#RequestParam("file") MultipartFile file)
throws Exception {
String baseUrl = serviceProperties.getAddress();
HttpEntity<MultiValueMap<String, Object>> request = createMultipartRequest(file.getBytes());
ResponseEntity response = restTemplate.postForEntity(baseUrl + "/api/upload", filterRequest, String.class);
return new ResponseEntity<>(response.getBody(), response.getStatusCode());
}

freediameter - No remaining suitable candidate to route the message

Well, I've started a simple project with freediameter library. what I need to achieve in my project is to create a client diameter application that could send some CCR request to a diameter server.
for this matter, I tried to create a new extension for freediameter daemon.
So, the first thing I did was to setup the peer diameter server in config file:
ConnectPeer = "vm-pc.my.domain" { No_TLS; ConnectTo = "192.168.56.2"; Port=3868; };
and then initialize a request message in ta_entry function, in message body i specified the Destination-Host and Destination-Realm but still I receive this error:
01/10/17,01:55:24.980611 ERROR Routing error: 'No remaining suitable candidate to route the message to' for the following message:
01/10/17,01:55:24.980620 ERROR 'Credit-Control-Request'
01/10/17,01:55:24.980628 ERROR Version: 0x01
01/10/17,01:55:24.980635 ERROR Length: 20
01/10/17,01:55:24.980642 ERROR Flags: 0xC0 (RP--)
01/10/17,01:55:24.980649 ERROR Command Code: 272
01/10/17,01:55:24.980656 ERROR ApplicationId: 4
01/10/17,01:55:24.980664 ERROR Hop-by-Hop Identifier: 0x00000000
01/10/17,01:55:24.980671 ERROR End-to-End Identifier: 0xDCA05EF4
01/10/17,01:55:24.980678 ERROR {internal data}: src:(nil)(0) rwb:0x0 rt:0 cb:0x80523df30,0x0(0x803397da0) qry:0x0 asso:0 sess:0x0
01/10/17,01:55:24.981562 ERROR AVP: 'Session-Id'(263) l=8 f=-M val="hadi-pc.my.domain;1484000714;6"
01/10/17,01:55:24.981569 ERROR AVP: 'Origin-Host'(264) l=8 f=-M val="hadi-pc.my.domain"
01/10/17,01:55:24.981577 ERROR AVP: 'Origin-Realm'(296) l=8 f=-M val="my.domain"
01/10/17,01:55:24.981584 ERROR AVP: 'Destination-Host'(293) l=8 f=-M val="vm-pc.my.domain"
01/10/17,01:55:24.981591 ERROR AVP: 'Destination-Realm'(283) l=8 f=-M val="my.domain"
01/10/17,01:55:24.981599 ERROR AVP: 'Auth-Application-Id'(258) l=12 f=-M val=4 (0x4)
01/10/17,01:55:24.981606 ERROR AVP: 'CC-Request-Type'(416) l=12 f=-M val='EVENT_REQUEST' (4 (0x4))
01/10/17,01:55:24.981613 ERROR AVP: 'CC-Request-Number'(415) l=12 f=-M val=2 (0x2)
Can anybody help me on this ?
ps: as I see in the logs the CER/CEA are normal.
What Origin-Realm was signaled in the Capability-Exchange-Answer message when the connection was established?
The Diameter request routing process (as described in https://www.rfc-editor.org/rfc/rfc6733#section-6.1) relies on the realm, so if the Origin-Realm returned by the peer is not "my.domain", freeDiameter will not route to this peer, even if the Origin-Host matches.