I have a web service that exposes data via HTTPS.
for example: https://www.sito.it/api/users?acces_token=sfkjsdbhfskjdb
suppose I have to query this web service from an app (android or any other platform).
if someone intercepts traffic between the server and the app, can they see the acess_token?
or not because everything is encrypted by HTTPS ??
When a secure connection is established between client and server, all the info about the connection (headers, parameters) is encrypted, so only emisor and receptor can see it.
What you have to take care with is not to have any intermediate proxy in a secure connection between client and server.
Click here for a much more extense and detailed explanation.
Related
I'm newbie of grpc and have played with simple grpc clients of java, go, and python. I know basic http and https but not familiar with protocal details. So this question may be rediculous to you but I didn't find any explaination online.
I know grpc has insecure(go: grpc.WithInsecure(), python: grpc.insecure_channel, java: usePlaintext()) and secure mode(TLS). and grpc is based on httpv2, and http has security mode(https).
So what if use insecure grpc with https? Is the overall data transfer safe?
And what if use TLS grpc with https? Is there performance overhead(becuase I think the messages are encrypted twice)?
Thank you for any answer, any exsiting webpages explaining such topic that will be best!
Insecure implies http. And TLS implies https. So there's no way "to use insecure grpc with https", as at that point it is then http.
There is no double-encryption. The gRPC security mode is the same as the HTTP security mode.
Using gRPC over TLS is highly recommended if you gRPC server is serving requests coming from outside(external network). For example you're creating front end app in javascript serving user requests. Your javascript app make call to your gRPC server for APIs your server provide. Your javascript communicate to your gRPC server through stub created in javascript end. At the end of your gRPC server, you need to set tls mechanism to secure communication between your javascript app and your gRPC server(because requests coming from outside).
gRPC somehow mostly used for internal services communication inside internal network in microservice architecture. You don't need to set tls for internal network usage since requests coming from your own environment from within your watch.
If you want to apply something like "gRPC over HTTPS", then you need something like gateway to map your http call to your gRPC server. Check this out.
You need to compile your proto file as gateway service definitions as well using provided tools. Now you can create your normal http server with tls enabled through something like http.ListenAndServeTLS(...). Dont forget to register your grpc server to the http server using the service definitions compiled from the proto file. With this all your requests to are encrypted with tls to your http server like normal rest apis do, but get proxied to gRPC server you defined. There's no need to enable tls at your gRPC server since it has been enabled in your http server.
My question is about networking. I'm just looking for a simple answer, yet I couldn't find one after 1 hour research. I know there are techniques such as Wi-Fi Hotspot, man-in-the-middle-attack, local network, echo switch, etc. But I couldn't find an answer to my specific question.
Let's say, client A wants to communicate with server B, and server B says client A must authenticate himself via HTTP basic authentication first. My question is, what happens if client A sends the authentication credentials via HTTP layer (insecure), who can read the HTTP headers that the client A sends to server B over the internet? Would it be easy to do that? Like placing a breakpoint between two arbitrary routers, which help to transfer the packets across the internet, in order to read those headers? How does it work in general?
Thank you!
PS.: I am not trying to learn and do it. I just want to know, how dangerous it would be, if the HTTP basic auth is made via the insecure HTTP layer.
Who can read the HTTP headers that the client A sends to server B over
the internet?
Your Network Provider (e.g Wi-fi hotspot Provider).
Your Domain Name System server (DNS, as 192.168.1.1).
Your Internet Service Provider (ISP).
Your Virtual Private Network if using one (VPN server).
Yourself Or a Virus.
and here comes the HTTPS (HTTP + SSL Encryption)
SSL is about communicating in a language that you and the server only understand.
How dangerous it would be if the HTTP basic auth is made via the insecure HTTP layer?
Well, from above, You can totally get that a simple virus or even a public Wi-fi Hotspot Device can capture and see all of your data if the communication was done in a plain HTTP Socket.
A Simple packet may contain all of your Device information including its basic contents as your passwords, credit cards information, The HTML form for the signup/login that you've just completed with all its data, VoIP Calls and messages being sent to the server + upcoming/received ones.
that's why we need SSL encryption and the server should have a valid SSL certificate too.
By the way, your device may have sent thousands of packets while you read this now!
Capturing the packets that your device sends or even the packets that other devices on your network send can be done through any packet capturing tool or software as Wireshark.
My application is based on Spring framework and is used to transmit very confidential data.During testing of the application with with proxy tools like Fiddler, Paros Proxy etc. it was found that these tools are intercepting the request data, and data is easily modified before reaching the server.
My application is not currently not integrated with SSL . We will implement SSL /HTTPS. but is this because SSL has not been integrated ?
Is it normal for Proxy tools to intercept the data from a web application with out HTTPS ?
There are two things here.
1) If you don't use SSL the communication is not encrypted, which means that anybody who is able to intercept the traffic, will be able to see the content. You don't necessarily need a proxy for that.
2) With an intercepting HTTP proxy you can see SSL encrypted traffic as well. What the proxy does is building two separate SSL tunnels one between the server and the proxy and one between the client and the proxy. This way the proxy itself can see the whole traffic. Of course the proxy can only provide a fake SSL certificate which will trigger a notification in the browser for the user, but he will probably ignore it.
Yes. If you don't use https, Proxy see everything that the application send or received.
To prevent that, you must use https.
To prevent sslstrip you must use HSTS.
As the title explains, I want to see the http requests that are sent by my android app client to my Jersey Web service.
Also, I'm using
https://github.com/kevinsawicki/http-request
class for sending the requests, but I'm not sure if they are SSL encrypted. Can I see if they are encrypted by looking at the http requests that arrive at my Web service?
If you have access to the server on which your web service is running, you can use Wireshark : https://www.wireshark.org/
This will trace and decode the tcp/ip protocol for you, and indeed show you if it's encrypted under SSL.
Assuming you own the server, and have full access, you can also install the Private Key from your server into Wireshark, and it will then show you decoded SSL traffic.
HTTPS is widely used for security online. It offers security and integrity, but not authentication. To ensure the client is not talking to a man-in-the-middle, we have digital certificates and the PKI. It all works very well, except in the situation where the following criteria apply:
The server and client do not share a common, trusted root CA, therefore they cannot validate each other's certificates
Circumstances (eg. firewall, permissions, etc) do not permit the use of regular HTTPS protocol
The question is: can we still send secure, authenticated messages between the client and server, perhaps using Javascript?
Something along the lines of:
Client sends regular HTTP request to server
Server responds with page containing Javascript code
Client's Javascript asynchronously sends data to the server used to negotiate
Server runs some sort of script (eg. PHP) to establish the tunnel
Client and server communicate over the encrypted tunnel
I can see it being possible to send messages with security and integrity in this manner, but is it possible to authenticate without making use of the PKI, perhaps by exploiting the fact that the server can dynamically rewrite the Javascript sent to the client?
There is an issue in your step 2 - Server responds with page containing Javascript code :
how do you know someone sitting on wire is not modifying this Javascript since it is being transferred in plaintext? Basically, when X wants to authenticate Y, X should know something about Y- it could be public information such as public key/certificate or shared secret that it could verify