Issue "Curl::Err::SSLConnectError"
Can any one tell me what will be the exact URL for Payflowpro now ,
the Url "https://payflowpro.paypal.com" does not work for me now.
It was working fine before but for some reason it gives me an error now.
Code in Lib file
Code in module
post_contents = Curl::PostField.content('TRXTYPE', 'S'),
Curl::PostField.content('TENDER', 'C'),
Curl::PostField.content('AMT', amount),
Curl::PostField.content('ORDERID', order),
Curl::PostField.content('CURRENCY', PAYPAL_CONFIG[:currency]),
Curl::PostField.content('CREATESECURETOKEN', 'Y'),
Curl::PostField.content('SECURETOKENID', secure_random),
Curl::PostField.content('PARTNER', PAYPAL_CONFIG[:partner]),
Curl::PostField.content('VENDOR', 'abababa'),
Curl::PostField.content('USER', 'abababa'),
Curl::PostField.content('PWD', 'abababa')
Logs Details
Started POST "/__better_errors/45429440/variables" for 127.0.0.1 at 2015-01-20 12:24:16 +0500
TRXTYPE=S
TENDER=C
AMT=5.99
ORDERID=1421738848U1
CURRENCY=USD
CREATESECURETOKEN=Y
SECURETOKENID=****
PARTNER=Paypal
VENDOR=****
USER=*****
PWD=*****
Rebuilt URL to: https://payflowpro.paypal.com/
Hostname was NOT found in DNS cache
Trying 173.0.82.162...
Connected to payflowpro.paypal.com (173.0.82.162) port 443 (#2)
successfully set certificate verify locations:
CAfile: none
CApath: /etc/ssl/certs
error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure
Closing connection 2
The reason for this is the change announced by PayPal.
Whoever is using the older SSLv3 needs to check their implementation of update their code to use the TLS version for curl.
PayPal provides info in this link.
That is still the correct endpoint. It looks like something going on with your DNS based on the message stating "NOT found in DNS cache."
You could try changing to use different DNS servers and see if that resolves your issue. For example, you could use Google's DNS servers or OpenDNS.
Google's DNS servers are 8.8.8.8 and 8.8.4.4.
Open DNS is 208.67.222.222 and 208.67.220.220.
Depending on your router you may be able to update the DNS server there, or you may need to do it from your local NIC card properties.
Related
I configured Gitea to authenticate against an AD server, and I'm receiving the following error:
[...dels/login_source.go:390 LoginViaLDAP()] [E] LDAP Connect error, my.ad.server.address.here:LDAP Result Code 200 "Network Error": read tcp <gitea host ip>:37590-><ad server ip>:389: read: connection reset by peer
What is strange to me is that the number 37590 in the example above always changes at each occurrence. Is it a port number? If true, how can I track it so I can whitelist it at the AD server firewall?
I'm a newbie in Go, so I can't figure out what's happening.
The 37590 that you see is the source port. It is the port that the server will use when replying and helps your computer know which application the response is for. It's normal for that to change on each request.
You are correct in thinking that this is a network problem. The error message "connection reset by peer" means that someone along the line (either a firewall along the path, or the host itself) closed the connection. (a little more detail here)
If it is a firewall that is not allowing you, then you need a rule allowing access from gitea host ip:any to ad server ip:389.
I discovered OpenSIPS and all the possibilities a few days ago. I would just use it as a simple SIP proxy to get started. Proxy between my designated UAC and my UAS (asterisk, not natted). The goal is to use a proxy to prevent bot attacks on my UAS.
After installing OpenSIPS, I tried to configure my XLITE (natted) by simply adding the proxy URL in the configuration. It works, I register and I can see in my UAS peers my extensions with proxy IP. But when I make a call, I got a forbidden error. In debug mode, the log does not talk to me, I see a lot of information but nothing about this error.
I did not make any changes to the default configuration script. Is this behavior normal?
I also tried with VM on public IP as UAC (so not named), same thing.
Thank you for your help.
Olivier
Most likely, your SIP INVITE is hitting this block:
if (!is_myself("$rd")) {
send_reply("403", "Relay Forbidden");
exit;
}
What this means is that your OpenSIPS does not consider itself responsible for the domain (or IP) that your SIP UA has placed in the Request-URI and is trying to route towards. To fix this, just whitelist the Asterisk IP as a local (recognized) domain using the alias statement:
listen = udp:*:5060
alias = 1.1.1.1
I'm reading the spec and trying to understand exactly when 421 might be returned. An example is given but I don't completely understand it.
Background
The spec establishes two conditions that allow for connection reuse:
For TCP connections without TLS, this depends on the host having resolved to the same IP address.
and
For https resources, connection reuse additionally depends on having a
certificate that is valid for the host in the URI.
If the certificate used in the connection has multiple subjectAltName or any of the subjectAltName is a wildcard, then the connection can be reused for any request that has a hostname that is in the list of subjectAltNames or matches any of the wildcards.
Specific Example In the spec
In some deployments, reusing a connection for multiple origins can
result in requests being directed to the wrong origin server. For
example, TLS termination might be performed by a middlebox that uses
the TLS Server Name Indication (SNI) [TLS-EXT] extension to select an
origin server. This means that it is possible for clients to send
confidential information to servers that might not be the intended
target for the request, even though the server is otherwise
authoritative.
Please explain where my understanding of this example is wrong:
An https connection is established to a middlebox with a request that has domain x.com. The middlebox has IP address 1.2.3.4 and x.com resolves to that address. Using SNI, the TLS handshake has x.com and the middlebox returns a certificate valid for that domain. All messages on this connection go from the client to the middlebox or from middlebox to client. Applicaiton level messages from client to middlebox are forwarded by middlebox to an origin on a different connection. Messages from origin to middlebox are forwarded to the client. If the connection is to be reused, meeting the two conditions discussed above is not enough. Specifically, for a request with domain y.com: if y.com resolves to 1.2.3.4 and the middlebox has a certificate valid for y.com, there can still be a problem. Because the original connection did its TLS handshake using x.com and because handshakes are only done at the beginning of new connections, there is no way establishing an https connection that would get the certificate for y.com. So the client incorrectly sends a request on the same connection to y.com. The middlebox rejects the request because the certificate associated with the connection is valid for x.com - not y.com. (The x.com certificate is only valid for x.com and the y.com certificate is only valid for y.com).
None of your examples will trigger a 421 as far as I can see.
Yes you are correct that a connection needs both the IP address and the SAN field in the certificate to be valid - without those a connection should not be reused.
So what would trigger a 421? As far as I can tell it will be mostly due to different SSL/TLS setups.
For example:
Assume website A (siteA.example.com) and website B (www.example.com) are both on same IP address. Assume website A has a wildcard cert for *.example.com and website B has a specific one. Could be a few reasons for this: for example it serves an EV cert for the main website which can't be a wildcard cert.
So cert A covers website A and website B. As does the IP address. So if you are connected to website siteA.example.com, and then try to connect to www.example.com then technically, by HTTP/2 standards, you could reuse the connection. But we wouldn't want that to happen, as we want to use our EV cert. So the server should reject with a 421. Now in this example the webserver is able to distinguish the correct host and has a valid cert for that host so could, in theory, serve the correct content under the wildcard cert, instead of sending a 421 - but since that wildcard cert is not defined for that virtualhost it should not do this.
Other examples include if you have different ciphers set up on different hosts. For example site A has super lax HTTPS config, because it's not really secure content and they want to reach even legacy browsers, but site B has super secure config and only accepts the latest TLS version and strong ciphers. Here you obviously wouldn't want them to reuse the same connection details. See here for a real would example of this.
Also this is only an issue for certain browsers, depending on how they decide to connection share. This page shows how different each of them do this (at least at the time of this blog post not not aware of anything changing since then): https://daniel.haxx.se/blog/2016/08/18/http2-connection-coalescing/
Also note that some bugs will exist with this (for example: https://bugs.chromium.org/p/chromium/issues/detail?id=546991). Best advice is: if you do not want connection sharing to happen, have a different IP address and/or ensure no overlaps in certificates.
I have problem, when I started my chrome, and try visit https page, i see this error:
Error 1013 Ray ID: 2cb7c5989ac13dd8 • 2016-08-01 08:03:08 UTC
HTTP hostname and TLS SNI hostname mismatch
You've requested an IP address that is part of the CloudFlare network. The request's Host header does not match the request's TLS SNI Host header.
What is it? where place cloudfare and how can I this remove from my browser?
SNI stands for Server Name Indication, essentially it allows you to serve more than one SSL certificate from more than one IP Address. Most modern browsers submit this as part of a web request. CloudFlare Free Universal SSL makes use of SNI.
Similarly, the Host header allows a server to know which hostname it should serve. The Host header fundamentally allows virtualhosting, serving more than one website per IP Address.
So these two clearly need to match, the SNI hostname and the hostname in the Host header must be identical. When this fails to occur CloudFlare will present a Error 1013 HTTP hostname and TLS SNI hostname mismatch.
There may be a proxy in your local network that is stripping out SNI headers or deforming them thus causing them to mismatch. This can happen as a result of a firewall or intermediary web server.
There is a tool here to check if your SNI header and Host header match. Simply visit the linked site and check the "SNI information:" field states "cc.dcsec.uni-hannover.de".
If you require support for browsers which do not support SNI, CloudFlare's Pro, Business or Enterprise support have legacy support for non-SNI browsers; but it would make sense to contact your network administrator to see why SNI requests are being malformed.
The tags on this question suggest you are using Firefox on Windows 10 which should support SNI; therefore you should reach out to your network team to see why they are malforming SNI requests.
I've been ripping my hair out for a few days over this and need help. I have a perforce server and an external client. Steps I've taken:
1. Opened port 1666 on my router (TCP and UDP) for my servers IP.
2. Allowed port 1666 through windows firewall.
3. I can connect to the perforce server from any system on the LAN by hostname or IP.
4. NETSTAT -a shows port 1666 is LISTENING.
5. External client can ping the server by external IP.
6. Internal client can telnet to the internal IP and port, external cannot.
I can not for the life of me figure out why the hell my external client cannot connect to the server. I am getting my external IP from "WhatsMyIP.org" and it matches my routers WAN address.
I have full on tried to disable windows firewall and still the same issue.
Please god someone help before I lose the rest of my hair.
EDIT1: I forgot to mention the error I am receiving from the external client:
Connect to server failed; check $P4PORT.
TCP connect to 99.252.60.60:1666 failed.
connect: 99.252.60.60:1666: WSAETIMEDOUT
You may want to take a look at your router's firewall rules in more detail.
I had a similar problem with my home setup that resulted in me having to modify some firewall settings on the router.
This KB also gives some information about the error:
http://answers.perforce.com/articles/KB/2960/
After working at this for three days, I found the issue with help from this forum post:
http://208.74.204.155/t5/forums/forumtopicpage/board-id/Getting_connected/thread-id/8923/page/1
My router model (Hitron Technologies CGN2-ROG) that I received from my ISP (Rogers up here in Canada) apparently doesn't play nice when it comes to port forwarding. With all of the EXACT same settings, I bridged that router to another spare I had laying around and it worked perfectly.
I literally just plugged in the new router and it worked without making any other changes at all.