Tag Info

Hot answers tagged

69

You should think of OSI layers as packaging. Let's say I want to ship a glass to you. I chose an original package for advertisement purposes, showing how nice is my product and what you can buy to add to your "glass" experience. That's the high layer of my protocol. Then I put this package in a box filled with soft thingies because I don't want it to be ...


45

Ordinary HTTP of all sorts is unencrypted. If you want to protect your data, it has to be sent over HTTPS.


32

With HTTPS the path and query string of the URL is encrypted, while the hostname is visible inside the SSL handshake as plain text if the client uses Server Name Indication (SNI). All modern clients use SNI because this is the only way to have different hosts with their own certificates behind the same IP address. The rest of the URL (i.e. everything but ...


18

There is a mechanism to allow secure authentication over HTTP without SSL or TLS, but it's rarely ever used, and it's still not as good as HTTPS. Basically, it's a half-assed security measure of historical interest that never caught on, and you really ought to just use HTTPS anyway. But since you asked…… The HTTP protocol supports two authentication ...


10

Both HTTP headers (containing requested URL) and application data in HTTPS is encrypted. You can see requested hostname, because browsers send it in Service Name Indication extension during handshake, so that server can choose matching SSL certificate.


10

While OSI is just a model, and in reality the layers can be blurred or nonexistent, the concept of layering protocols is specifically to allow a change in a particular layer to leave the layers above and below it alone. As an example: Physical - does a basic packet care whether it is travelling over copper, fibre or wireless? It could travel over all ...


7

First, a couple of points. In any cryptographic system that does not provide information-theoretic perfect secrecy, the key can always be brute-forced. One of the key components of determining whether a cipher is secure is whether or not it is feasible to brute-force keys, and if it is, the cipher is not secure. So, brute-forcing the key isn't an ...


7

Using wireshark, you will be able to find out the host name, as mentioned by some other answers, due to SNI. Also, you'll be able to see some parts of certificates. The https URLs you've seen were probably the URLs of CRLs or OCSPs. If someone could get at your URLs by walking your site, and compare the size of the returned pages with the size of what's ...


6

Don't mistake security with privacy. The task of SSL/TLS is security, not privacy. This means the data itself are encrypted but meta data like source and destination IP, hostname (with SNI as used by all modern browsers), payload size and timing etc are not. And all these can be used to make a browsing profile of you which includes the sites you visit and ...


5

The asymmetric cryptography establishes a shared secret, which is called, in TLS terminology, the master secret. The master secret is fixed throughout the session; a TLS session consists in one or several connections (opening a new connection while reusing the master secret is called session resumption and uses the "abbreviated handshake"). For each ...


4

To answer the question you posed: Yes, credentials are most likely being sent in the clear. The only time Fiddler would be able to see the cleartext for the credentials, while the credentials are being sent encrypted, is if you've enabled the SSL proxy in Fiddler and configured the client devices to either trust the Fiddler Root CA or ignore the certificate ...


3

You're so very close to the name of the Firefox/Iceweasel plugin you need with your question title! Tamperdata: https://addons.mozilla.org/en-us/firefox/addon/tamper-data/ You could also use one of the Web proxies shipped with Kali, OWASP-ZAP or Burp Suite. You may want to gloss over the manuals for these, but in general you start them up, aim your ...


3

TCP provides to applications a stream interface. There are a few exceptions where the details leak through, but generally a TCP socket is opened, and then each side sends a series of bytes to the other. Those bytes will be delivered intact and in order, up until the point where the remote end closes the connection (which you will be informed of). ...


3

You seem to misunderstand both the same-origin policy and CSRF. The same-origin policy is crucial for any kind of browser security. It makes sure that client-side scripts from one website cannot access information from another site. Without this, we'd have much bigger problems than CSRF: Any website could read our e-mails with our webmail account (while ...


3

It is possible to perform traffic analysis by crawling the website and comparing packet sizes, etc. Depending on how much dynamic content is present or images referenced from the URL it is possible to get a very accurate understanding of which URLs where visited. The presentation SSL Traffic Analysis Attacks - Vincent Berg (YouTube) explains it and has some ...


3

SSL/TLS doesn't hide the source and the destination IP addresses. It is impossible (at least, with a purely ssl/tls solution), because the src/dst addresses must be valid to a working tcp connection. The name of the connected website, is hidden by default - or, at least, it was until the last some years. Since then, there is an extension of the TLS named ...


2

As the other have stated, the initial connection is unsecured and contains IP address at least (though increasingly server name as well thanks to SNI). The destination server responds with a public key certificate and they negotiate the SSL/TLS session. The key to avoiding man in the middle attacks is the certificate and the fact it's been approved by a ...


2

Http Https +------------------+ +------------------+ |7 http methods | | http methods | <---same No change needed +------------------+ +------------------+ |6 data:ex)"$1000" | | data:ex)"kf4d3s1"| <---data encrypted +------------------+ +------------------+ |5 Sock: | | Sock: | ...


2

It would be possible for your application to authenticate securely over HTTP if the website (and your application) implemented the SRP protocol (Secure Remote Password). Note that it would only be secure for applications implementing the SRP protocol, not for users accessing the website with a browser, because if the JavaScript code required to make SRP ...


1

Any node at any point along the traffic can sniff the traffic, including all the ISPs along the way. The question, then, is what threats you wish to mitigate? If you what to protect against "small-time" attackers, then any point within the ISP's network is safer and you only have to worry about the ingress and egress points (server, client, local network ...


1

Your biggest risk would be older versions of Internet Explorer that attempt to auto-detect the encoding as UTF-7 - called Codepage Sniffing. It appears that Internet Explorer will only do this for webpages, and not for AJAX requests. Therefore JSON requests should be safe. Moreover, JSON requests do not cause rendering of content directly to the page - they ...


1

Assuming you're running a Linux system, have you considered iptables? Basically, you could use something like: iptables -A INPUT -p tcp -dport 80 -m limit --limit 20/second --limit-burst 50 -j ACCEPT And use some tweaks to whitelist/blacklist. This way you won't have to restart any service. See this resource or this one, and This anwser on ...


1

This is just like moving vehicles on the road. Like road is the fixed medium and on it many types of vehicles can run and so if you make new vehicle for it to run on road the vehicle must have tyres that could run on that road. Similarly if you consider Ethernet as one medium it could carry various networking protocols like IPv4 or IPv6. So the point over ...


1

Yes you are correct and that "is" considered a vulnerability and or a usable exploit. although link shortner providers will say otherwise because there is all ready a fix for this, See services like to is used for hyper linking and a less cluttered text. To be safe and fix this all you must do is right click the link and click copy copy clink location and ...


1

High level protocols may not be secure when used, unchanged, with SSL. There is a possibility of side channel attacks. As others have explained well, SSL allows you to wrap an unencrypted stream in an encrypted one. In theory, no information about the data being transmitted should be leaked. In practice, there's one piece of data that always leaks - the ...


1

After establishing a secure connection, a web browser will still ask the same type of question such as GET /som/page.html HTTP/1.1 host: www.example.com and the web server will still respond the same way 200 OK Content-Type text/html ... The only difference is that underneath this conversation we do not have a straight TCP connection but instead ...



Only top voted, non community-wiki answers of a minimum length are eligible