This might be silly question as I am very new to this. Please help me knowing the details:
I have only below information for a application:
1) Application is accessed using https through browser
2) Application talks to LDAP over SSL connection for authentication purpose
Now, my question is, if there would be some relation between SSL used by https and the SSL which application is using to communicate with LDAP?
Can we disable SSL so that application is accessed using http but the communication between application and LDAP is still over SSL?
There is requirement to change https to http because of some compatibility issue.
Thanks in advance.
Now, my question is, if there would be some relation between SSL used
by https and the SSL which application is using to communicate with
LDAP?
No, those are 2 different connections. In the first case the client is the browser and the server is your application and in the second case the client is your application and the server is LDAP.
Can we disable SSL so that application is accessed using http but the
communication between application and LDAP is still over SSL?
Yes, absolutely. Of course that would mean that the users passwords will be sent as cleartext between their browsers and your application. Depending on your scenario this could be acceptable but for a publicly facing website I would rather say that this is bad practice.
Related
What's the best security practice to follow while using PouchDB on the client-side to access a remote server?
The example on https://pouchdb.com/getting-started.html syncs with the remote server with the code:
var remoteCouch = 'http://user:pass#mname.example.com/todos';
The problem is I probably don't want the user to see the plaintext password with a file they can download -- even if that file is shown to the authenticated users only.
Please advise. Thanks in advance,
Here's a really good article regarding all things auth for CouchDB.
I've got a production server with CouchDB configured to use HTTP over localhost but external requests require HTTPS redirected via stunnel to CouchDB.
On the client I use PouchDB to maintain a local, replicated db. As part of the handshake to establish communication with CouchDB over HTTPS, the software acquires CouchDB credentials from another server - the credentials are never stored client side.
pouchdb-authentication is a good plugin, but I've found it better to handle auth personally.
Every site user should have his own CouchDB user. As #onno suggests, use HTTPS and the user's login credentials to access CouchDB. Passwords should never be available in client-side JavaScript.
This depends on your remote server. If you use a CouchDB server, you could configure it to communicate only via SSL (HTTPS), see the docs for details.
If you don't want to expose your CouchDB server directly to the internet, you could also hide it behind a reverse-proxy, e.g. an Apache server with the mod_proxy extension and SSL enabled.
I am developing a backend for a mobile application using Node.js to handle HTTPS requests. I have set up an SSL to connect from the client to the server and was wondering if this was secure enough.
I don't have experience with intercepting endpoints from the mobile devices, but I have seen that it is possible for people to monitor internet traffic out of their cellphones and pick up endpoints to server requests. I have seen hacks on tinder where people can see response JSON and even automate swipes by sending http requests to tinder's endpoints.
My real concern is that people will be able to update/read/modify data on my backend. I can implement OAuth2 into my schema as well but I still see cases in which people could abuse the system.
My main question is whether or not using HTTPS is secure enough to protect my data, or if a session authentication system is needed like OAuth2.
Thanks.
HTTPS, providing it is properly configured, will ensure the message was not read or changed en route and that the client can know the server it is talking to is not a fake.
It will secure the transport. It will not secure the application.
For example supposing you have an app that allows you to send a message saying https://www.example.com/transfermoney?from=Kyle&to=BazzaDP&amount=9999.99 and the server does just that based on those parameters. Then I could send that message myself - I've no need to intercept any app messages.
Normally the server needs authentication as well as HTTPS to, for example, verify only Kyle user can send above message and not anyone else. HTTPS normally only gives server authentication not client authentication (unless using two way certificate HTTPS).
So the question is, even if an attacker cannot read or alter any messages between app and server can they still cause harm? That is the measure of whether it is secure enough.
A SSL connection is only secure with the content you are sending.
SSL encrypts and ensures the authenticity of the whole connection, including the requested method and URL
So i would say just using the SSL encryption is save to transfer data between - i might consider OAuth2 for password etc.
But i would recommend to use GET for retrieval data and post for authorized data
You're building an armored tunnel between two open fields.
Assuming that you use current SSL protocols and settings, and valid certificates from trusted issuers, you can pretty much assume the network is OK.
However it's still entirely possible to compromise any or all of your transaction from the client. Security really depends on the device and how well it's configured and patched.
After taking a look at the HTTP State Management Mechanism Spec specifically 4.1.2.5 where it mentions:
The Secure attribute limits the scope of the cookie to "secure"
channels (where "secure" is defined by the user agent). When a
cookie has the Secure attribute, the user agent will include the
cookie in an HTTP request only if the request is transmitted over a
secure channel (typically HTTP over Transport Layer Security (TLS)
I was wondering if my setup has this set up correctly. I have a hapijs server and an nginx proxy server that it sits behind. The nginx server is configured for HTTPS (I can access it via https://..., anyway). Now there are ways to provide certs to the hapijs server to provide it TLS. My question is: is this necessary? The connection between the user's browser and my server is protected with TLS and then all that communication happens without sending anything over the wire so I would assume it would be okay.
I may be way off base here so maybe someone can point me in the right direction if I am.
The "secure" attribute of cookies is handled by the client (the web browser) and not by any proxy servers (at least that that I'm aware of!).
So you should be fine as long as the endpoint the browser connects to is secure.
This is a very common set up to only secure traffic at the end point - providing you are comfortable with the the security of the link between endpoint and final destination (e.g. same machine or internal network).
Of course an internal network traffic can be sniffed by someone onsite (e.g. an employee) so https all the way is best from a security point of view, but using http from endpoint to final destination should not prevent "secure" cookies being sent on from my experience.
If using external network as the first server (e.g. CDN) then it's strongly advisable to use https all the way to a secure endpoint, though again they will not be stopped.
I have this web app that is served via https, and now it needs to use a websocket service that is served from another server. Chrome, Firefox and Internet Explorer complain right away that if the application is secure (https), then it is not allowed to connect to an insecure websocket service (ws:// URI). Strangely, Apple Safari doesn't complain so.
Well, fair enough, I assumed any globally trusted certificate would be fine to be installed at the websocket server side, to enable secure service (wss:// URI). However the company that maintains the socket server claims that they have to install there the very same certificate that secures my web application. I read in webs that the wss will not run with self-signed certificate, but nowhere that it must be the same certificate that the calling web site runs on.
Since we are talking sharing a certificate key file with 3rd party, I wanted to double check this. If my secure site runs at domain first.com, and the websocket server at IP address a.b.c.d, what kind of certificate should be installed on the websocket server to enable the communication? On one hand, that would be a kind of cross-site scripting, but perhaps the browser security model allows it, assuming the user knows what they want?
What I understand from above, the browser connects to your web application and is then redirected to the other server. If that be the case, then browser would complain about being redirected to unsecured site from a secured URL. The way forward actually depends on the domain of the server that the redirect is happening to, for example, if your main site has URL form www.mainsite.com and the target site has URL form abc.secondsite.com or an IP, the second server must have configured an SSL certificate that has been issued to either abc.secondsite.com of the IP i.e. the name of the host requested must match exactly with the SSL ceritficate that is provided by the secondsite.
The secondsite technically does not have to have the same certificate as your mainsite, it just have to be a certificate issued by a trusted source (like Verisign etc.).
On the other hand, if you have a wildcard subdomain certificate i.e. a certificate issues is valid for all the *.mainsite.com domains and the URL form of the secondsite is sub_domain.mainsite.com, then the same certificate can be used on both the servers.
Hope this helps.
thanks
Since we are talking sharing a certificate key file with 3rd party, I
wanted to double check this. If my secure site runs at domain
first.com, and the websocket server at IP address a.b.c.d, what kind
of certificate should be installed on the websocket server to enable
the communication? On one hand, that would be a kind of cross-site
scripting, but perhaps the browser security model allows it, assuming
the user knows what they want?
You cannot provide a certificate for an IP address. In order to use WSS:// you need to connect to a domain name, and have a valid certificate for that domain name. So you need a SSL certificate for the domain name of your WebSocket server.
As far as I know, it does not need to be the same than the one on the site. You can check by entering here: http://vtortola.github.io/ng-terminal-emulator/ and executing the command websocket wss://echo.websocket.org, you will connect to a WebSocket in websocket.org that echoes your inputs.
WebSockets are not constrained by the SOP (Same Origin Policy), you can connect anywhere, and the server is responsible of checking the HTTP request header "Origin" and accept or refuse the connection.
I am developing a Node.js app based on the Express framework. On the backend, I need to have servers talk to each other (ie. Server 1 make a request of Server 2).
Is it OK to forego a DNS A-Record and just use the IP address of the server?
In that case, how do I authenticate the server and "client" (aka server). I was thinking of requiring the server and "client" to each pass a secure cookie with their request and responses. The secure cookie would then be verified before any other action was taken.
Using a IP might be more secure then DNS (e.g. no DNS spoofing), but it still allows ARP spoofing, e.g. some other computer claims to have this IP. And in case both computers are not in the same network there are also ways to hijack requests in routers etc.
The secure cookie is nothing else as a shared secret. And contrary to public key based authentication (e.g. using certificates) shared secrets have the disadvantage that you need to distribute them in a secure way so that nobody else gets access to them.
I don't think that your idea is easier to handle than SSL with certificates, so I don't see an advantage of making your own secure protocols. History tells us, that such homegrown protocols mostly provide worse security than established solutions.
If you don't care about security (these hosts are on your network, in which you have trust), don't bother with the homebaked cookies.
If you do care about security get (or generate your own) certificate and use SSL.
I was thinking of requiring the server and "client" to each pass a secure cookie with their request and responses. The secure cookie would then be verified before any other action was taken.
This is not secure at all! Anybody situated on an appropriate network between the client and server can see that "secure cookie", as well as any subsequent communications. This would allow them to reuse that cookie themselves to impersonate either the client or server, and would expose any sensitive information sent in the exchange.
Use SSL. It has already solved all of these problems, and more.