get.page says that .page domains require https
What differences do .page domains provide?
Why does ellen.page say Not Secure and show an error?
The reason you are seeing the “Not Secure” warning is because the web page or website you are visiting is not providing a secure connection. When your Chrome browser connects to a website it can either use the HTTP (insecure) or HTTPS (secure). Any page providing an HTTP connection will cause the “Not Secure” warning.
Hypertext Transfer Protocol Secure is an extension of the Hypertext Transfer Protocol. It is used for secure communication over a computer network, and is widely used on the Internet. In HTTPS, the communication protocol is encrypted using Transport Layer Security or, formerly, Secure Sockets Layer.
The Hypertext Transfer Protocol is an Session layer protocol for distributed, collaborative, hypermedia information systems.
HTTPS is HTTP with encryption. The only difference between the two protocols is that HTTPS uses TLS (SSL) to encrypt normal HTTP requests and responses. As a result, HTTPS is far more secure than HTTP. A website that uses HTTP has http:// in its URL, while a website that uses HTTPS has https://.
.page domains are different because they require HTTPS certificates.
ellen.page normally uses encryption to protect your information. When Google Chrome tried to connect to ellen.page this time, the website sent back unusual and incorrect credentials. This may happen when an attacker is trying to pretend to be ellen.page, or a Wi-Fi sign-in screen has interrupted the connection. Your information is still secure because Google Chrome stopped the connection before any data was exchanged.
Related
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.
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.
I want to use secure websockets with socketio and nodejs so that more of my mobile traffic/corporate networks can utilise websockets.
What level of SSL certificate is required for most browsers to accept the certificate/server as trustworthy. Browsers don't have an interface for reviewing/allowing SSL connections for websockets as far as I know, so how do they handle a cert they don't trust? Do they just refuse the connection?
What minimum level is required from an example list: https://www.123-reg.co.uk/ssl-certificates/ and has anyone done any research into how browsers handle various levels of SSL in websocket connections?
Securing a websocket is no different to securing an HTTP connection. A TLS handshake process will happen first to establish a secure connection and then an HTTP connection will be established over this secure link. For a websocket the additional step of upgrading the HTTP session to a socket will be taken. What this means is that whatever works for HTTPS will work for WSS. This link has a useful diagram.
I'm not sure what the difference is between the "123 SSL" and "Domain SSL" levels in your link, if the lower cert is issued against your domain it may be fine. Generally you want "Domain Level Validation" or above - it is enough to secure traffic between clients and your server. As long as the root certificate is trusted (generally the company you are buying the certificate from), browsers will accept this with no message or warning. For WSS, APIs and communicating with mobile apps this will be fine. The top level certificate (Extended Validation or EV) has the added advantage of additional security indicators in the browser (usually the green address bar or lock), great for browser sites but not of much use for pure WSS or API clients.
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.