Our system only has a HTTP Smart Service feature to connect to external system.
If the target external system we are trying to connect to is “https” then does that make it secure?
We are just putting an authentication token in the header.
Absolutely not.
There are many factors that make it secure vs insecure. HTTPS is just one piece of the puzzle. If HTTPS used it might mean that the connection is encrypted and no one can eavesdrop, but being 'secure' can mean a lot more things.
Related
I set everything well and some https request did be proxied well, but some are still unknown , is there any new way I don't known to prevent being proxied ?
I found that the https connections checked the cert on apps their own. Which means you can't just add the cert to your device's system and hope it works.
There are more works should be done to capture these data by using proxy.
More detailed things are you have to hack the app to capture. For those information just google "JustTrustMe".
I need to develop a Facebook app, and while I request my SSL certificate, I need to start the project because I have few time to deliver it.
Is it possible to use localhost as the "Secure Canvas URL"? This field requires that the URL begins with https, so I don't know the correct way to do it (in the case that using localhost is allowed).
First of all you need to set up your server to answer HTTPS requests.
Then you create a self-signed SSL certificate – not sure if that works for the domain name localhost, but I’d recommend setting up a local domain, such as mytest.local anyway (the .local being the important part here), make your server listen to that, and your system resolve it to your local IP address, f.e. via its hosts file.
And then you tell your browser to accept that self-signed certificate … and you’re good to go.
I'm building a RESTful API which is only accessible by TLS. Where should SSL connection be implemented?
by RESTful API itself, my API is written in golang, which handles SSL easily.
by a SSL reverse proxy, here I'm using nginx.
I would prefer 2nd approach because nginx handles caching and static deliveries better.
Should I implement my API HTTP-only now? In my opinion the system is secure, as long as nginx the reverse proxy is serving SSL only and my API exposes itself to nginx only.
I'm not sure if there is a 3rd approach, while I keep my API SSL only and nginx passes through all requests transparently.
TL;DR: I will choose between the 2nd or 3rd option, depending on the scenario. If you want to publish the API on Internet, never opt for the first one.
The most secure option is the third one: implement your API to allow SSL connections only, and publish to Internet using a reverse proxy anyway.
The pros are the communication with your API will be secure even for internal connections. That will give you protection from internal attackers. The cons are the extra processing load on your server to manage the SSL security and that can impact on the performance.
Anyway, you should look for cost-benefit. That's the reason why it will depend on the scenario. For example, if your API will not be accessed by internal users, but only for internal services, and the load on the server is heavy, you can consider the 2nd approach: plain HTTP por internal communications and SSL termination for Internet.
I hope i am at the right place asking this question, its regarding understanding of SNI
According to https://devcentral.f5.com/articles/ssl-profiles-part-7-server-name-indication#.U5wEnfmSzOz
"With the introduction of SNI, the client can indicate the name of the server to which he is attempting to connect as part of the "Client Hello" message in the handshake process"
My question is how does client like browser or any HTTP client (say java.net) send this server name in CLIENT HELLO?? Does client do by itself or you have to add it Programmatically to https request (e.g how in JAVA.net HttpsURLConnection)
Reading from http://www.ietf.org/rfc/rfc4366.txt
"Currently, the only server names supported are DNS hostnames"
so the hostname is the server_name sent by SNI complient client or any other name can be sent by the client..
I hope i am clear, do improve the question/wording if its unclear or let me know if its not clear
thanks
If you are using an https library, which you can give a URL and the library will fetch the contents of that URL for you, then the clean way to add SNI support is to perform it entirely within the library.
It is the library which parses the URL to find the hostname, the caller will never know which part of the URL is the hostname, so the caller couldn't tell the library which hostname to send in the SNI request. If the caller had to somehow figure out the hostname in order to tell this to the library, then that would be a poorly designed library.
You might look a level deeper in the software stack and find that an https library might be building on top of an SSL library. In such a case even the https library does not need to know about SNI. The https library would simply tell the SSL library, that it want a connection to a particular hostname. The SSL library would resolve the hostname to get IP address to connect to, the SSL library would also be performing the SSL handshake during which the client may send a hostname as part of SNI and the server send a hostname as part of a certificate for the client to verify.
During connection setup, the SSL client library need to use the hostname for three different purposes. It would be trivial to support the usage of three different hostnames for those three purposes. The https library already know the hostname, and passing that hostname three times to the SSL library rather than just one wouldn't be any significant amount of additional work. But it would hardly make sense to support this anyway.
In fact SNI could be entirely transparent to the https library. It would make sense to extend the SSL library with SNI support without changing the API to the https library. There is little reason to turn off SNI support in a client, which supports it. So defaulting to having SNI enabled makes sense.
I need to setup a cron job to run a SOAP client. The customer insists that I connect to their web service (on an https address) from an https address. They insist that if I don't their response to me can't be encrypted.
My first question is, is that true? I thought that as long as I'm connecting to their SOAP service over https, the response back would automatically be encrypted.
If that's true, how can I run a cron job to be as https? My site is on a LAMP setup with cPanel access.
Thank you in advance for your help!
Your customers statement seems to be a little bit unclear in what he/she specifically means by "... connecting from an https adress" as there isn't any notion of the term "https adress" in the specs and https URLS only seem to make sense in the context of Request-URI s given in a https request.
Given this unclarity I'm only wild guessing. Nevertheless to me it seems your clients requirements might most probably not be connected to the http protocol but rather to establishing your TLS connection.
If your client is very sensitive in respect to the security of his system - which in fact if he intends to offer RPC requests might be a very good idea - he might not want to the whole world to be able to connect an encrypted connection to his machines and rely on any secondary authentication mechanism once the connection has been established.
As most users of the public internet don't have any certificates signed by a trusted authority this feature it isn't used out in the open wild but besides server authentication the TLS handshake protocol also provides a means of client authentication via client certificates (the relevant part being section 7 in RFC 5246 here. see: https://www.rfc-editor.org/rfc/rfc5246#section-7)
While in the absence of widely used client certificates web services usually rely on establishing an encryted connection to first to authenticate users by some kind of challange response test like querying for username and password your client might want to either additionally secure access to his machines by additionally requiring a valid client certificate or even - probably not the best idea - replace a second authorization like the one already mentioned above.
Nevertheless all this are nothing but some ideas that I came along with given the riddle in your question.
Most probably the best idea might be to just ask your client what he/she meant when saying "... connecting from an https adress"