Tag Info

Hot answers tagged

81

All except the third link refer to SSLv3 (version 3) which is affected by the poodle vulnerability. You should be using the TLS protocol which is the successor of SSL and not affected. You should configure your web server to support TLS 1.0, 1.1 and 1.2, which should cover most devices out there save for a few archaic ones like IE6.0, while still remaining ...


26

You're running into a bit of terminology confusion. SSL can mean two things: The Secure Sockets Layer protocol, versions 1, 2, or 3. The generic SSL/TLS family of security protocols. SSL definition 1 is thoroughly obsolete and should not be used. SSL definition 2 is still very much alive, with the good pieces of SSL definition 1 (such as much of the ...


12

No, it isn't safe because you expose (in your program) a key which should be secret. Your proposal is based on symmetric key cryptography, where both ends of the communication channel need a copy of the same key. Symmetric key cryptography is effective only when both ends of the channel are secure. As others have pointed out, a key embedded in a program ...


11

Infosec Island: IPv6 - The Death of SSL The article talks about the use of IPSec as integral part of IPv6 instead of SSL/TLS. IPSec mainly moves the encryption from application layer to the transport layer. But, the main problem with SSL/TLS are not flaws in the protocol or in the crypto code. Instead the main problem is the PKI, that is the proper ...


10

Aside from the other good answers about the SSL vs TLS vs certificate confusion, the question of whether you should continue to "buy" a SSL certificate may be influenced by the upcoming launch of Let's Encrypt (sponsored by the EFF, Mozilla, et al), which will start offering free and turnkey SSL certs in 2015. Unless you need a fancy certificate (EV, ...


7

To expand on Thebluefish's answer, the form submission process appears to use HTTPS (an encrypted protocol) for the credit card element to https://connect.firstdataglobalgateway.com/IPGConnect/gateway/processing when I am looking at the page. But this does not mean this setup is safe to use. The overall setup is very vulnerable and needs to be fixed. I ...


4

No, this is not a secure alternative. It is entirely possible that a hard-coded key could be discovered, which would leave you with application traffic that is essentially unencrypted. So, if you feel the data is not sensitive enough to secure, don't bother encrypting it at all. Deliver it over HTTP. If, however, there is any reason to secure it, do ...


4

HTTPS over UDP is secure. This is because the security of HTTPS doesn't use any of the properties of TCP except that it is a transport layer. Just like UDP, TCP is easy to spoof and manipulate. TCP is only to make things more reliable, not more secure. With UDP, packets can be doubled, missed or sent in the wrong order. TLS is a means to fix these issues. ...


4

This sounds like a story that has grown massively in the telling. In August, Google announced that https websites would get a small boost in their search rankings compared to http sites. That's all; the http sites won't be marked or flagged as insecure. On your point 2, SSL providers are likely to get poorer, not richer, because the EFF is launching a new ...


3

If you look at the source code regarding the credit card form, you can see the following: <form name="form" method="post" action="https://connect.firstdataglobalgateway.com/IPGConnect/gateway/processing" id="payForm"> Therefore the form submission is over HTTPS. This should be fine in ensuring your credit card details are not stolen, though your ...


2

Yes, the Chrome team ("Google", if you wish) intends to "gradually change their UX to display non-secure origins as affirmatively non-secure" [1]. The exact implementation details are still a subject of discussion (see the "Proposal: Marking HTTP As Non-Secure" on the browser's mailing lists), and as such it is a bit premature to make any claims about how ...


2

If there is code executing in the same context of your web application, whether it was part of a XSS attack in the browser, or some malware/virus on the users machine, it would be difficult (impossible?) to differentiate those requests from your own. If the attacker has access to the computer, they could also just steal the data from your applications ...


2

Send a request to a server you control and see it it was altered in transit; you may also use a online service like HTTPBin, it's designed to test HTTP client libraries and has pages that return the exact request content, so you'll see if additional cookies were added. Note that ISPs can be sneaky about this and only add the cookies in requests to their ...


2

Yes, it's possible and it's trivially easy. You can make it a bit harder by using HTTPS and a pinned certificate but that will not stop anyone with a bit of time on their hand (they will then need to modify your executable, or, at least, the container where you placed your pinned certificate) and it will make it harder to manage your server (because if you ...


1

When I googled the query, I received many similar requests reported as malicious on different websites (like this one). This certainly looks like an XSS attempt. However, I don't think there's anything to worry about this particular request. The code: ...


1

Anything sent in a request using the HTTP TRACE method will be echo-ed back in the response. This may lead to Cross Site Tracing (XST) attacks, which could lead to steal a user's cookie even if the cookie has the HTTPOnly attribute flag set. The HTTP TRACE method is used for debugging purposes only and should be disabled. Apache Configuration: ...


1

It's a server configuration issue. No, I don't know why your server is configured to do this, since it's generally a bad idea. Using my general-purpose HTTP diagnostic tool, wget, to retrieve https://www.w1office.com/CSS/all.min.css, I get: Connecting to www.w1office.com|91.151.215.29|:443... connected. HTTP request sent, awaiting response... 200 OK ...


1

In spite of being possible to read/write data to SSL/TLS channels as with vanilla TCP/IP sockets, in Java or C or whatever, SSL provides you the concept of SSL session, which can be kept across several TCP/IP connections. Thus, IMHO this makes SSL a session layer protocol (I wonder why someone came up with the TLS name...).



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