Pros and cons of disabling TCP timestamps

The disadvantage would be that the TCP sequence could wrap. This is a risk on very high speed networks. You can randomize the initial timestamp, however, just as you asked. It's a very simple patch, so any rejects will be trivial to fix. It requires the grsecurity patchset to already be applied.

From https://grsecurity.net/~spender/random_timestamp.diff:

diff --git a/grsecurity/Kconfig b/grsecurity/Kconfig
index 3abaf02..700e56c 100644
--- a/grsecurity/Kconfig
+++ b/grsecurity/Kconfig
@@ -925,6 +925,16 @@ config GRKERNSEC_RANDNET
      here.  Saying Y here has a similar effect as modifying
      /proc/sys/kernel/random/poolsize.

+config GRKERNSEC_RANDOM_TIMESTAMPS
+   bool "Add random offset to TCP timestamps"
+   default y if GRKERNSEC_CONFIG_AUTO
+   help
+     If you say Y here, a simple change will be made to TCP timestamp
+     behavior that will prevent the system from leaking the jiffies
+     value remotely to an attacker who has not been persistently
+     monitoring the system since boot.  The jiffies value can be used
+     to remotely determine system uptime.
+
 config GRKERNSEC_BLACKHOLE
    bool "TCP/UDP blackhole and LAST_ACK DoS prevention"
    default y if GRKERNSEC_CONFIG_AUTO
diff --git a/grsecurity/grsec_init.c b/grsecurity/grsec_init.c
index ae6c028..c7dbe97d 100644
--- a/grsecurity/grsec_init.c
+++ b/grsecurity/grsec_init.c
@@ -7,6 +7,11 @@
 #include <linux/percpu.h>
 #include <linux/module.h>

+#ifdef CONFIG_GRKERNSEC_RANDOM_TIMESTAMPS
+__u32 random_timestamp_base __latent_entropy;
+EXPORT_SYMBOL_GPL(random_timestamp_base);
+#endif
+
 int grsec_enable_ptrace_readexec;
 int grsec_enable_setxid;
 int grsec_enable_symlinkown;
diff --git a/include/net/sock.h b/include/net/sock.h
index b2948c0..ccbeda9 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -2296,4 +2296,8 @@ extern int sysctl_optmem_max;
 extern __u32 sysctl_wmem_default;
 extern __u32 sysctl_rmem_default;

+#ifdef CONFIG_GRKERNSEC_RANDOM_TIMESTAMPS
+extern __u32 random_timestamp_base;
+#endif
+
 #endif /* _SOCK_H */
diff --git a/include/net/tcp.h b/include/net/tcp.h
index 44a58b0..fcdca06 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -684,7 +684,11 @@ void tcp_send_window_probe(struct sock *sk);
  * to use only the low 32-bits of jiffies and hide the ugly
  * casts with the following macro.
  */
+#ifdef CONFIG_GRKERNSEC_RANDOM_TIMESTAMPS
+#define tcp_time_stamp     ((__u32)(jiffies) + random_timestamp_base)
+#else
 #define tcp_time_stamp     ((__u32)(jiffies))
+#endif

 #define tcp_flag_byte(th) (((u_int8_t *)th)[13])

diff --git a/net/core/dev.c b/net/core/dev.c
index f3e28ec..8b1cf12 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -6986,6 +6986,10 @@ static int __init net_dev_init(void)

    BUG_ON(!dev_boot_phase);

+#ifdef CONFIG_GRKERNSEC_RANDOM_TIMESTAMPS
+   random_timestamp_base += prandom_u32();
+#endif
+
    if (dev_proc_init())
        goto out;

Note that newer kernels have integrated something similar to this in the time since this was posted.


Why fear hardware brought to China, when most of it comes from China?

Because they had to be subtle when they bugged all the hardware in the world, the same as we had to be subtle when we bugged all the operating systems in the world, for fear of being caught.

But when they have physical control of a specific targeted machine, then they can be much less subtle.


Let's get into the details of what a guest session is on Ubuntu. You've asked 'is it more secure for the system to use a guest session rather a normal account?', and the answer is yes, but only slightly.

Guest sessions use a tmpfs instead of a home, so data does not get written to disk but stays in RAM. This means a prolongated session with important amounts of changes might cause your system to need swapping.

As far as I understand a user is created and deleted every time, albeit I haven't found the corresponding code in LightDM and the guest-sessions tree on Launchpad.

Processes in the session can only create TCP and UDP connections, although I'm not sure what the expected security benefits are (apart from preventing PPTP tunnels?).

AppArmor is used to ensure that this session cannot possibly write to the system, except for its own home and /tmp. This should normally cover cases when a root privilege escalation occurs within the guest session, but not attacks against the kernel itself. A regular account would not provide you with this kind of protection.

https://wiki.ubuntu.com/DesktopTeam/Specs/Intrepid/GuestAccount


Proper Format for Long-Term Storage on M-Discs

The first hit for me when searching for long term document storage format is Recommended Preservation Formats for Electronic Records from Smithsonian Institution Archives. There is a table with recommended formats which clearly shows PDF/A and PDF as the preferred format for Text/word processing applications.
Similar recommendations can be found on the later search results from other archives and libraries, and these likely know best.
It is actually no surprise that PDF/A is chosen - because it was actually designed for this purpose. The "/A" in PDF/A stands for Archiving, i.e. this is a version of PDF specifically designed for long-term archiving while still preserving the original formatting.


Fingerprinting users based on IP addresses

It could, and it does, but not as much as you'd think. Your IP address can be unique or it can be different on a per-user bases.

If you live alone and have your own cable model, then - for a while - you'll have a unique address. However, at some point, your lease will be up and you'll be assigned a new address and somebody else will be assigned yours.

If you live with a family, then all of you use the same cable modem and same IP (i.e. the IP you got from the last person who lives alone), so now your address represents multiple people.

If you're using a cell connection, you're almost certainly sharing an IP address with everybody else - and your IP may change from tower to tower or faster.

Basically, IP addresses are an unreliable indicator of identity.


Is it possible for me to extract my own AES disk encryption key?

Yes, as a general rule Full Disk Encryption software - especially business products like Checkpoint - includes some way of backing a recovery key up. Check the documentation or ask your IT department.

By the way, it's not using your Windows logon. After all, windows is on the encrypted disk too, so it has to be unlocked long before you get to the logon prompt. If you are not being prompted for a password, it's likely using a TPM chip that automatically decrypts the drive whenever you power up the machine, so the key isn't even stored on the disk.


I think I accidentally DoS'd a website. What should I do?

First off, let me say this: I respect the ethics of anyone who would ask this kind of question (rather than just closing their eyes, walking away, and forgetting the whole thing).  My compliments to you.

Ultimately, this is a matter of personal ethics, so it is hard to give advice.  You need to do what you feel is right.

That said, your suggestion to try contacting the site owner seems reasonable to me.  I suspect that any harm done will be minor or that the cost will be minor.  Normally, the cost of bandwidth is pretty modest, in monetary terms.  But the site owner might appreciate hearing that his/her site is unreachable, and appreciate the apology.  But it's up to you, and what feels right to you.


IPSEC - Remote Access Clients, Tunnel or Transport Mode?

Client-side VPNs (AnyConnect, RDP) use transport mode because they set up end-to-end or end-to-site encryption. They do not rely on any other security infrastructure to create and maintain the tunnel.

Tunnel mode is most often done between VPN gateways (routers) that maintain the tunnel without needing to install or configure the clients.

Some clients can make use of VPN gateways as well, but when your client is "all alone", they use transport mode.


Is SSH secure and what are the recommended modes of operation?

The SSH protocol is from the same era as SSL (the 1990s) and shares a lot of common principles. Both are relatively complex assemblies of several cryptographic algorithms, and SSL in particular served as a testbed for many novel attack techniques related to side-channel leaks (see this answer for a summary of attacks which have met some success with some versions or implementations of SSL). SSH seems to have less suffered from SSL, mostly because:

It is a lower-value target. A cryptanalytic paper which breaks some facet of SSL is more likely to get some non-academic attention than a similar paper which concentrates on SSH; and "attention" correlates (loosely, but still) with prospects of future funding.
SSL is used in HTTPS, i.e. the Web, and Web browsers are marvelous engines that can, in particular, run the attacker's code (with Javascript). Thus, chosen-plaintext attacks are much easier to demonstrate with SSL than with SSH.
SSL's public key management relies on X.509 certificates, and thus inherited all the relevant troubles. The public key distribution in SSH is much more primitive and lacks the flexibility of X.509, but it is also much harder to break (the SSL model strives to allow a client to securely connect to a server to which the client has never talked to yet; in the SSH model it is merely asserted that this problem is handled "out of band").

In any case, the developers of OpenSSH (the main SSH implementation nowadays) keep an eye on known attacks on SSL; and for the elementary cryptographic algorithms, OpenSSH uses the code from OpenSSL (the very classic and widely used opensource implementation of SSL). Thus, some attacks on SSL which could have been adapted to SSH have been preemptively countered that way.

The cryptographer's point of view is thus that the SSH protocol is roughly on par with SSL. SSL is the most attacked communication protocol, but also the most repaired, and every single novel attack has been tried against it, so we may say that SSL (and thus SSH too) is extremely secure -- as long as you dutifully apply security updates on implementations.

When looked at closely, you will see some cryptographic-level differences between SSL and SSH:

The SSHv2 protocol always uses a Diffie-Hellman key exchange; the server's private key is used only for a signature. This is similar to the "DHE" cipher suites in SSL, and provides Perfect Forward Secrecy. This is a good thing (it means that stealing the private key of a server does not allow decrypting previous connections that the attacker could have recorded).
The symmetric encryption layer combines encryption and a MAC in a mode known as "encrypt-and-MAC", distinct from the "MAC-then-encrypt" used by SSL (see this question for details). Both modes, though, are relatively poor, and require great implementation care to be secure (OpenSSH developers did take care).

In practice, the biggest vulnerability of SSH, by far, is the human user. Servers get broken into through SSH, not because of a cryptographic vulnerability of the protocol, but because either some remote hole was found and exploited in the server code, or the user's password or private key was stolen (typically because of some client-side malware). The really important step that must be taken is to make sure that security updates on both the server and the client are applied with all the possible alacrity.

Remember that SSH is, by nature, a way to remotely control a machine. It is a hole in the server's defence perimeter. A user who can SSH into a machine can then potentially run every possible "local exploit" against that machine. Believing that a given computer is safe against local privilege escalation would be overly optimistic; making the system secure against remote exploits is already hard work. Therefore, don't give SSH accounts away needlessly.

And use a strong password ! (See this for inspiration.)


Browser Updated, yet still vulnerable to POODLE

Some companies have proxy servers that perform a MITM attack on all https traffic going through a company.  So while SSL3 may be disabled on your browser, it might not be disabled on the proxy server, and the proxy server is what establishes the SSL connection to the test servers you're accessing.

If that's the case, you need to update your proxy server to disable all SSL3 traffic if you want to be sure to be safe from POODLE.


How to safely setup user rights inside a backup folder?

set the sticky bit on /backup  (that's how /tmp works)

chmod +t /backup
chmod ugo+rwx /backup


I want a full time career in the field of security. The following is my plan. Any suggestions or modifications?

Certifications will only carry weight in certain industries and on certain teams. In my experience, they're great for doing security consulting, but not so much for impressing a company's InfoSec team.

Of the certs you mentioned, the only one that carries weight is the OSCP, and unmentioned CISSP is kind of a standard cert.

What type of security do you want to do? digital forensics? Incident response? In-house security team (defense/blue team)?

The security field has a bunch of cool areas you could get into, it'd be helpful to know where you want to go so we can rescope the question (What is a good career path for X infosec job?)


Is it possible to send encrypted data over an unencrpted network while hiding the fact that it is encrypted?

Yes, this is known as steganography. In order to hide the encryption, it requires a lot of background "noise" which is itself a decoy signal - so the cyphertext is much larger than the clear text. A common method for acheiving this is to hide a text message inside an image.

There are several examples on github


can wpa2 wifi be hacked by capturing data on an evil twin?

I'm going to assume you mean WPA2-Personal AES in particular in this answer.  If you mean WPA2-Enterprise, it's a whole different kettle of fish, and if you mean anything less, the access point owner (and perhaps users) should upgrade.

Essentially, the answer is no, a MITM "Evil Access Point" never gets the actual passphrase.  They pass a nonce (salt) back and forth, information on protocols supported, etc., but both the Access Point and the Station construct the key themselves.

Therefore, an evil access point cannot "phish" the key from the client during 802.11 operations.

You can see this "in action" in sniffer traces at Cisco's 802.11 Sniffer Capture Analysis - WPA/WPA2 with PSK or EAP

Now, an Evil Access Point that can hear both the Good Access Point and the Station can capture 4-way handshakes and then use the usual tools to perform brute-force, mask, and rules-based dictionary attacks, but it doesn't need to broadcast anything to capture that if the clients are authenticating on their own.

For a phishing attack, an attacker is down to sending emails, or having their Evil Access Point not use WPA2, which should be a red flag to users.

If you are using WPA2-Enterprise, perhaps try the surprisingly readable Benefits and Vulnerabilities of Wi-Fi Protected Access 2 (WPA2) , which does cover other standards.


Are Apple Magic Keyboards Secure Against Man-in-the-Middle Attacks?

Regardless of the specific keyboard model you asked, the range for wireless functionality is way less than what a drone could eavesdrop. You use the magic keyboard indoors, so there's no point in talking about drones.

Anyways, I recommend this Hacktivity presentation to get a closer glimpse about how wireless keyboard exploits work. https://www.youtube.com/watch?v=JPaiqJIMFCU


Something I've learned from experience: developers (myself included) can and WILL forget things. SQLi is a great example: if you rely on developers to use an escape_string(user_input) every time it's used, they WILL forget.

Ditto XSS and XSRF: developers will always miss at least one place that strings can be escaped. And CSP isn't a 100% fix for XSS.

It's absolutely critical that frameworks/libraries are used that are invulnerable to those problems (or where opt-in is necessary). I don't know ASP.net specifically, so I can't really recommend one, but a term to look for is "contextual auto-escaping" (for XSS).

In terms of other problems, I suggest checking out the OWASP Top 10 - they do a pretty good job of showing what the important thing is.

One thing I'd watch out for especially is "insecure direct object reference" or "forced browsing" - ensuring that ACLs are applied at every page load. And going back to the first thing I said, they should be applied automatically - the developer shouldn't have to remember to do it. Any insecure behaviour should be explicitly opt-in.

Hope that helps!


While you can do this yourself, I would argue that unless you are a malware researcher there is almost no value in running real malware through your antivirus solution. As @chutz answered, EICAR is useful to trigger A/V if you must but testing for it is almost pointless these days. If you have an AV solution, whether it be standalone or enterprise level, the only useful checks are:

Is it turned on
Is it set to scan on file open
Is it set to scan on file receipt
Is it set to run a full scan on a regular basis
Are the signatures up to date

It is a pretty mature industry - leave the vendors to do the testing of their signatures. If it passes those checks I listed, that's about all you can ask for.


Ways to generate symmetric and asymmetric keys

You seem to ask for a comparative study on the PRNG (pseudo-random number generators) used by default by OpenSSL and the Linux kernel. This could most probably fill a volume full of mathematical formulas, and to make it worse OpenSSL and the Linux PRNG are not independent since OpenSSL will use /dev/urandom as a default seed, and there are ongoing work to provide an alternative PRNG for Linux (you can see Stephan Müller work on the subject here and there and also his discussions on the linux kernel mailing list).

However, the fact is that in most cases both will share the same strengths and weaknesses:

Strength: both are mature and well audited code generally accepted as cryptographically secure PRNG,
Weakness: as their name state they both are pseudo random number generator, meaning they both are deterministic algorithms which, given the same seeds, will produce the same output. The unpredictability of the produced numbers is therefore directly dependent on the unpredictability of the seeds.

So, security-wise, your main concern here may not be which one from OpenSSL or /dev/urandom to use (especially when you know now that the former relies on the latter behind the scene), but to ensure the quality of the seeding. In particular, what you may want is one or several sources of TRNG (True Random Number Generator), ie. some hardware component specially designed to serve unpredictable random data suitable for cryptography.

This will guaranty you that the quality of the seeds used by the above mentioned algorithms will not be dependent on external factors as the system I/O, load, etc. (when available these entropy sources will most likely still be used, but merged with the TRNG input). In most situations, this will have more impact on your overall keys strengths than choosing between two well-established PRNG implementations.

Now to answer your doubts:

  Doubt 1:

  How does the length of the key, e.g. 128, 192 or 256, affect
  encryption and decryption? Is is only time taken for encryption and
  decryption?

Yes, it is: larger key require more computational power to encrypt and decrypt. The idea behind this is that, while it will require more efforts from the legitimate devices knowing the right key, it will also require "exponentially" more effort from any potential attacker.

Regarding the right length, you will already find a lot of discussions on this website on this subject (like this nice table), with some general cases and some taking some constraints into account (like embedded devices which have very limited computational power).

  Doubt 2:

  Which method is more random, Method 1 or Method 2? I am inclined to
  think that Method 2 is random enough and the manual page of random,
  urandom suggest to use urandom in case one is not sure about it.
  However we have seed enough entropy to generate more secure random
  number.

Method 3 may block suddenly and for an undetermined amount of time. If this not what you want (and usually you don't want this), then the choice is indeed between methods 1 and 2.

From there, the choice is merely a matter of personal preference. I would say that the syntax using OpenSSL is more portable, and easier which can help to avoid bugs (for instance using -n (number of lines) instead of -c (number of bytes) as parameter of the head command ;) ).

  Doubt 3:

  Can we ask OpenSSL to take random number from /dev/urandom?

This is the default behavior, but if you want to ensure this OpenSSL documentation is your friend and would advise you to add the -rand parameter:

openssl rand -rand /dev/urandom 128 > sym_keyfile.key

  Doubt 4:

  Is OpenSSL help suggesting to use pkcs#8 for generating both the
  private and public key or only for generating the public key from the
  private key?

As stated in LvB comment, this is about how the keys are stored, and not generated (this is like storing a file in either a .zip, .rar or .tar.gz archive).

In case you have a free choice, OpenSSL indeed advises you to use modern and standardized formats instead of the historical SSLeay format:

With PKCS8 you will store the private key in one (possibly encrypted) file, and the public key / certificate in another (plaintext) file.
With PKCS12 you will bundle both the private and public components in a single file (which may seem more practical but implies that if the .p12 file is encrypted, then even the public certificate will not be readable without deciphering the file first).

Practically, the choice will often be down to what is supported by the applications which will use the keys. Its documentation will often mandate you where and how to store the key material.

  Doubt 5:

  Do you suggest any other method to generate more secure asymmetric
  keys?

I already mentioned TRNG devices above, and I would also advise you to stay on known land by using mature and well known software implementations. Software implementing poor algorithms or good algorithms but with a buggy implementation can equally annihilate your security.

And at last, stay informed since mistakes can happen everywhere, but they are most likely to be detected and solved soon in well-established solutions than in exotic ones.


Storing email addresses in plain text is okay?

Nowadays with all the related data privacy regulations in place where it mandates protection data on transport and data on rest.

Hence you should encrypt those email address, which is considered as PII, when storing to database. Now this comes another level complexity since you need to protect your key that will be used for encrypting/decrypting.

What will you get? Well a solution that is partly compliant to data privacy regulations. This will add value to your solution especially if you are working or with a partnership with big companies (they have huge risk in case data breach will occur in terms of reputation).


An attempt to overcome the key distribution problem inherent in one time pad cryptography

On a general basis, we don't want to encourage this kind of question:

References to code are not good descriptions of cryptographic algorithms. Good descriptions use the language of mathematics, not programming.
A description on a set of files on github is not permanent enough; if you ever change it, then this will make this question unreadable.
There is a very inefficient and tiresome cycle, which goes thus: "Hey, I don't know the subject, but I have this idea; is it secure ? -- No, it is not, for this reason. -- What if I add a +1 there ? -- No, does not help. -- Then what if I also put a +2 at that place ? -- ..." Experience shows that this kind of process never ends up with a good algorithm; however, it produces long-winded awful discussions. It is already bad enough on Usenet groups like sci.crypt; on a Q&A site like this one, it will just not do.

From a cursory look at your files, though, it appears that you want to use Shamir's three-pass protocol. This requires a commutative cipher such that you can encrypt a message with key u, then with key v, and then decrypt with key u and v in that order, and get back the original message. Unfortunately, commutative ciphers are hard to make without a lot of mathematics, like modular exponentiations modulo big primes.

Your idea to do multiplications modulo 2n and to "encrypt" only message values x which are not invertible modulo 2n is not secure. Indeed, from the outside, the attacker sees x*u, x*v and x*u*v (all values modulo 2n). Since x is even, there are integers m and y such that y is odd and x = y*2m. u and v being odd (that's necessary for them to be invertible), the observed values are necessarily multiple of 2m and not 2m+1. In other words, expressed in binary they all end with exactly m zeros.

The attacker's goal is to recover x. He already knows m, as explained above. He wants y, which has length n-m bits. By simply dividing all the values he observed by 2m, he gets y*u, y*v and y*u*v, all values modulo 2n-m, and they are all odd, hence invertible. It then suffices to compute (y*u)*(y*v)/(y*u*v) (modulo 2n-m), which yields y. End game.

The above generalizes to all computations modulo some integer N when taking x to be non-invertible modulo N.

I encourage you to do your homework, i.e. read the Handbook of Applied Cryptography, which is a free download and very good reading (if a bit terse at times). Shamir's three-pass protocol is described in chapter 12, page 500. Mind the following passage:

  While it might appear that any commutative cipher (i.e., cipher wherein the order of encryption and decryption is interchangeable)
  would suffice in place of modular exponentiation in Protocol 12.22, caution is advised. For
  example, use of the Vernam cipher (§1.5.4) would be totally insecure here, as the XOR of
  the three exchanged messages would equal the key itself.

The worst sin in scientific research is to disregard previous research.


TLS Renegotiation Indication Extension vulnerability

Marsh Ray's blog seems to be down at the minute, but you can read more on Eric Rescorla's blog (I'm using the same example application data here) or in this PDF (archive.org copy).

The genuine client sends a Client Hello (GenCH) to the server, but this is intercepted by the MITM.
The MITM keeps hold of it and starts its own handshake by sending a a Client Hello (MitmCH) to the server too. It completes the handshake normally and sends some application data. For example:

GET /pizza?toppings=pepperoni;address=attackersaddress HTTP/1.1
X-Ignore-This:

The MITM now forwards the initial Client Hello (GenCH) to the server.

As far as the client is concerned, this is not a re-negotiation, but the initial negotiation. It can't tell the difference. The handshake completes and it sends its own request:

GET /pizza?toppings=sausage;address=victimssaddress HTTP/1.1
Cookie: victimscookie

As far as the server is concerned, receiving a second Client Hello (GenCH) is just a re-negotiation (which either party was able to initiate at any point in time) following the initial handshake initiated with  Client Hello (MitmCH). The application layer is treated as continuous. This is what the server sees:

GET /pizza?toppings=pepperoni;address=attackersaddress HTTP/1.1
X-Ignore-This: GET /pizza?toppings=sausage;address=victimssaddress HTTP/1.1
Cookie: victimscookie

This way, the attacker is able to alter the request line (and thus query parameters) and insert its own headers, while keeping the cookies of the genuine client. The MITM doesn't get to see or alter what the client sends, but it's able to add content before, which is treated as part of the same request on the application layer.


Is there a difference between "risk tolerance" and "risk appetite"?

The best way to distinguish the two can be using mathematics.
Risk Appetite is the target level of loss exposure that the organization views as acceptable, given business objectives and resources. Think of this as amount of money an organization can afford to lose (Eg - 10k $).
Risk Tolerance is the degree of variance from the organization’s risk appetite that the organization is willing to tolerate. Think of this as how much percentage of the intended loss budget can be covered, or how much flexible is the loss budget. (Eg - 5%)

Now look at the examples - the company has a risk appetite of 10k $. This implies that the company can afford to lose 10k if there is a breach, breakdown or any issue. Risk Tolerance is how much this number can vary - implying that the 5% shown tells us that the Max limit the company can push it loss budget is (10k + (5% of 10k)) which is (10k + 500)$. Here, 10k is appetite and 500 is tolerance.


Is using bcrypt on existing SHA1 hashes good enough when switching password implementation?

Actually this is a good way to protect the otherwise unsecurely stored passwords. There is one weak point in this scheme though, which can be overcome easily in marking old hashes, so I would prefer this solution:

if (checkIfDoubleHash(storedHash))
  correctPassword = bcrypt_verify(sha1(password), storedHash)
else
  correctPassword = bcrypt_verify(password, storedHash)

Imagine an attacker getting hold of an old backup. He would see the SHA hashes, and could use them directly as passwords if you test with bcrypt_verify(...) or bcrypt_verify(sha1(...)).

Most bcrypt libraries add a mark of the used algorithm themselves, so it is not a problem if you add your own "double hash mark", but of course you can also use a separate database field for this:

$2y$10$nOUIs5kJ7naTuTFkBy1veuK0kSxUFXfuaOKdOKf9xYT0KKIGSJwFa
 |
 hash-algorithm = 2y = BCrypt


HMAC and using a cryptographically safe random field as message

A unique (often random) element added to a message is called a nonce. It can be used as a defense against replay attacks (that is, an attacker who can observe a correctly signed legitimate request could later replay that exact request to cause the server to take the same action again). As such, it can be very useful (assuming you verify that a given nonce can indeed be used only once).

However, if I understand you correctly, you want to compute the MAC for the nonce/salt instead of for the actual message data. This will not work, as only the parts of the message that are included in the MAC are protected, of course. I suggest you serialize your entire message into a suitable format (e.g. JSON), compute the MAC over it, and send both in the request. That way, the MAC/signature is not a part of the message proper, and verification can be done without knowledge of the message's structure itself.


Is it secure to share an access token via HTML5 messaging API between various iframes?

The postMessage API  is designed for cross domain communication as part of the Cross Origin Resource Sharing mechanism.
The Window.postMessage() method, introduced in HTML5, allows JavaScript code running on different origins to communicate with each other in a bidirectional manner. This API can be used for communication between an iframe and its parent document. Similarly, it can be used by an HTML page and a child window to exchange messages, such as an embedded third-party video notifying its parent frame when the user pauses the video.
The classical rules of security also apply to applications using postMessage(). You are planning to use this method for sharing authentication information which is perfectly fine if you you follow basic input validation rules while implementation.

Never broadcast your auth tokens: Your scenario contains multiple different parties who need to have access to a common token. you might be tempted to broadcast the authentication information so that all the iframes get access to it. This may result in unauthorized access to your tokens. Hence the postMessage() call should always specify the target origin.

Always validate message origin:  You need to validate that the message has been received from a valid and expected origin. Only after origin validation you should proceed with using the message in the application logic. Imagine a case where your app is iframed by a malicious domain. If you do not validate the origin of the message it may result in script injection.

Additionally, depending on your trust relationship with the authorization server, you may want to validate the token itself once the sender origin is validated.
For a more detailed analysis of postMessage() API security along with a few example code snippets, refer to my Blog


PHP encrypt and decrypt with certificate

Generally speaking, asymmetrical encryption is safer than symmetrical because remote end can only decrypt data, with no possibility to encrypt. The key is only useful for decrypt, server encrypt with a different unpublished key.

Even with self signed certificates, in my opinion security is enhanced comparing to symmetrical encryptions solutions. Go for it.


Yes, SSL Inspection is essentially a man-in-the-middle "attack" (except it's not really an attack since it's being done by the infrastructure owner) with the intention of being able to read all traffic originating from your company machine or crossing your company network, even if SSL is being used.

Consequently, you should not send anything from your company issue machine, or over your company network, that you do not want your corporate security team to read.

(Which is a good general rule in any case.)

Some other points to bear in mind:

A reasonable company will not care about your personal data.
An ethical security team will go to some lengths to avoid seeing personal data
A sensible company will have documented what they will and won't do - see what's been published.
There is a small but non-zero risk with any such system that a real attacker will compromise the monitoring system.
There are other methods available to a corporate security team for monitoring computer use - they can deploy keyloggers, for example.

If an organization has to implement a robust Data Loss Prevention system, they're going to have to look at everything - so even though they are implementing SSL Inspection it doesn't mean they have evil intent. Not much fun for their employees, of course, which is why transparency is so important.


How to stop my phone from secretly recording me?

This depends on your threat model. If you are not a high-value target, then you don't have that much to worry about.

Of course, the best way to prevent someone gathering incriminating evidence on you is to prevent that evidence from being created in the first place. If you have any reason to believe that someone is wiretapping you, don't have any electronic devices near you when you have sensitive conversations. In fact, be careful with sensitive conversations in general. Adversaries can use lasers to listen to your conversations, without the need to directly attack your mobile phone.

If you suspect that your neighbor is trying to wiretap you, then hold sensitive conversations outside of your apartment. Your car may be a suitable place, given that it's a moving target. The car of your conversational partner may be an option as well. You will have to weigh how much you trust the Operational Security of your conversational partner, compared to your own.

If this gives you major tinfoil-hat vibes, then you are indeed correct. These approaches are not practical for everyday life, but then again my everyday conversations rarely get more exciting than "Is there anything you need from the grocery store?", so I doubt any Triple-Letter Agency (or MI5) are particularly interested in that.


Do I need to patch Linux for Meltdown/Spectre if the hypervisor has been patched, and I trust the guest?

To answer the question you originally asked: whether or not you're running untrusted code, if you want to protect against Meltdown or Spectre, you still need to upgrade your kernel, even if your cloud provider has patched the underlying hypervisor.

The GCE customer announcement (linked from the Google security blog post, which is a bit light on detail but also links to the project zero writeup which is full-on) says under “Mitigation Status”:

  Infrastructure patched against known attacks. Customers must patch/update guest environment.

If you don’t trust Google, AWS has their own security bulletin which states:

  While the updates AWS performs protect underlying infrastructure, in order to be fully protected against these issues, customers must also patch their instance operating systems. Updates for Amazon Linux have been made available, and instructions for updating existing instances are provided further below along with any other AWS-related guidance relevant to this bulletin.

The reason why this is necessary is because paravirtualization allows the guest kernel to have control over the TLB in the CPU directly, without mediation from the hypervisor (it’s one of the major performance improvements of paravirt over full virt, along with direct I/O). Thus, if the guest OS kernel doesn’t implement the mitigations, processes running in the VM can still grab data from the kernel and other processes running in the same guest.

The answer to the second question you've edited your question to add, as to whether you're at risk from your neighbours, appears to be, with the information currently available, "no".  The answer to the third, seemingly implied question, of whether you should patch now or in your regular patch cycle, isn't answerable with the information you've provided, as it is deeply rooted in your own organization's risk profile and threat models, and I'd go so far as to say that you're bordering on "primarily opinion-based" with that one.


What are these unknown visits to my private, unlisted webpage?

There are multiple possible explanations.

The first one and the most likely (especially if the secret part of your url is not that long), is plain and simple bruteforce. If you're on a popular website, it really shouldn't surprise anybody that they are being scanned in order to find some juicy hidden urls. Given the fact that they are hitting your page with another hostname, I'd guess it's a pretty credible possibility.
The second one is that since you communicate with third parties on your page, your url was eventually leaked & sold (by google analytics, by the website host, etc).
The third one is that at some point, either your connection to the website or your email has been sniffed. In both case, your website eventually ended on a list of urls to scan.


Dangers of Electron's "shell.openExternal" on untrusted content

I think your confusion stems from your interpretation of the term "remote code execution" (RCE). This term is used to describe (perhaps colloquially) many different classes of critical software vulnerabilities that allow an attacker to execute arbitrary code or commands on a vulnerable system. The particular vulnerability may be a result of a memory corruption bug, a logic error, poor software development practices, or a combination of the above.

Vulnerabilities like the one described in your question allow for "arbitrary command execution". These are also referred to as "command injection" vulnerabilities in web application security, and perhaps elsewhere. In this case, your assertion is correct that it is not literally "remote" code that is being executed, but an attacker can still run potentially arbitrary commands on the system. While not as flashy as a memory corruption bug, where the attacker may hijack the program's instruction flow and possibly execute their own shellcode, it is still critical, as the attacker is not restricted, other than by nature of the openExternal function.

Here are some examples of what an attacker could do with this vulnerability:

# Sure, harmless enough
shell.openExternal('file:///Applications/Calculator.app')
# What if you provide a file URI to a network share that contains a malicious app?
shell.openExternal('file://net/203.0.113.0/nfs/evil/malicious.app')
# Or SMB share?
shell.openExternal('\\203.0.113.0\evil\malicious.exe')
# Maybe in some cases it is bad enough to just run a program with no arguments? (Rough example)
shell.openExternal('file:///bin/telnetd')
# Or maybe it could be combined with some kind of file upload to use an attacker's uploaded file.

Additionally, some apps may register custom URI protocol handlers such as x-custom-app:// that may allow an attacker to open an app and supply it with whatever commands/data it supports.

I suggest you search online for bug bounty writeups that used openExternal. Here are some things I found:

https://pwning.re/2018/12/04/github-desktop-rce/
https://hackerone.com/reports/276031
https://dev.to/nlowe/rce-in-mattermost-desktop-earlier-than-420-5aef


Does the SSL termination happen with the ISP or a mobile service provider?

Not, it is not true...

.. Unless the ISP is good at spying on people, and you are gullible. In that case, things are possible.

Explanations: to "snoop" on your communications, the ISP must either break the SSL crypto (fat luck on that) or impersonate the server to power a Man-in-the-Middle attack. From the client's point of view (your Web browser), the server's public key is obtained through the server's certificate. The certificate is validated relatively to the root CA which are embedded in your computer. The ISP will not be able to obtain a fake certificate mimicking that of the server you are trying to talk to.

Spying on you thus requires at least one of the following:

The ISP is in league with a big commercial CA, and can obtain fake certificates. This is highly improbable because such certificates would be so many proofs that the CA is dishonest, thus making the game highly risky, for the paltry gain of simply spying on your data.
You get a big red flashy warning from your browser about the server certificate being invalid in some way, and you click on "I know what I am doing" (which, in this case, would be a quite bad idea).
The ISP could convince you to install some software of theirs on your computer. E.g. a "connection kit". That software, if malicious, could install an extra root CA certificate under control of the ISP, thus allowing the ISP to generate fake server certificates and thus succeed at MitM. (Similarly, the same software could plant some spying tool such as a key logger.)

I am not aware of any actual case of an ISP spying that way on its customers, in supposedly democratic countries (I have heard stories about institutional MitM with rogue root CA in some countries like Iran, though -- but I don't have any confirmation about it).

Without an actual SSL break or rogue CA, the ISP can still see what servers you are trying to talk to, and may try to infer some clues about the contents of the exchanged data based on its size (encryption hides the values of byte, but leaks the message sizes). For an organization who wants to keep track of a lot of people, such metadata already constitutes a lot and is what they will concentrate first, to identify interesting targets.


Can a Malicious App with Storage permissions access a Secure App's data

As Google documentation (https://developer.android.com/guide/topics/data/data-storage) says:

  By default, files saved to the internal storage are private to your
  app, and other apps cannot access them (nor can the user, unless they
  have root access). This makes internal storage a good place for
  internal app data that the user doesn't need to directly access. The
  system provides a private directory on the file system for each app
  where you can organize any files your app needs.

  When the user uninstalls your app, the files saved on the internal
  storage are removed. Because of this behavior, you should not use
  internal storage to save anything the user expects to persist
  independenly of your app. For example, if your app allows users to
  capture photos, the user would expect that they can access those
  photos even after they uninstall your app. So you should instead save
  those types of files to the public external storage.


No. Not unless you have physical access to it and it is your cabinet/rack. It is likely they will have ISO 27001 certification already. If not you could require it of them. Or at least the right to audit.
It is likely that your scope will be something like the protection of customer and corporate data in the provision of health-related analytics
Location office @ ABC Street


Can Hacker Post data through GET request?

The hacker does not POST the data. POST is a HTTP method as much as GET, HEAD, OPTIONS and similar. Contrary to GET the POST method can have a request body to transfer the data. Still, it is possible to transfer data within a GET request too, for example inside the query string of the URL (i.e. the part starting with ?) like you see in the logs. There is nothing special about it and in fact this is the way data are transferred if you use a HTML form and don't explicitly specify a method.
And since this is just normal behavior the server will return a successful response code.


Current best practices to prevent persistent XSS attacks

Since you want current best practices and the latest answer here is August 2012, I thought I might as well weigh in and update this.
Best practises to prevent any type of XSS attack (persistent, reflected, DOM, whatever).

Strictly validate all input. For example, if you're asking for a UK postcode ensure that only letters, numbers and the space character is allowed. Do this server-side and if validation fails, display a message to the user so that they can correct their input. Do this for all variables outside of your control, including query string, POST data, headers and cookies.
Add yourself some security headers. Namely

X-XSS-Protection: 1; mode=block to activate reflective XSS browser protection into blocking mode instead of filtering mode. Blocking mode stops attacks like this. Edit 2021-01-28: This header is now deprecated due to browsers like Chrome discontinuing their inclusion of XSS auditors.
X-Content-Type-Options: nosniff to prevent JavaScript being inserted into images and other content types.
Content-Security-Policy: with strict script-src and style-src's at least. Do not allow unsafe-inline or unsafe-eval. This is the daddy of headers for killing off XSS.

Follow the rules in the OWASP XSS (Cross Site Scripting) Prevention Cheat Sheet when outputting values, however for rule #3 I'd do the following instead:

Use HTML data attributes to output anything dynamic on the page.
e.g. <body data-foo="@foo" />
Where @foo will output an HTML encoded version of the variable. e.g. " /> would give <body data-foo="&quot; &#x2F;&gt;" />
Grab these values out using JQuery or JavaScript: var foo = $("body").data("foo");
This way you don't need to worry about any double encoding, unless your JavaScript later inserts as HTML, however things are still simpler as you deal with the encoding there too instead of mixing it all together.
Use a function like below to HTML encode if you're using document.write, otherwise you could introduce a vulnerability. Ideally though use textContent or JQuery's text() and attr() functions.

Tackle these in reverse order. Concentrate on #3 as this is the primary mitigation for XSS, #2 tells the browser not to execute anything that slips through and #1 is a good defence-in-depth measure (if special characters can't get in, they can't get out). However, #1 is weaker because not all fields can be strictly validated and it can impair functionality (imagine Stack Exchange without the ability to allow "<script>" as an input).

function escapeHtml(str) {
    return String(str)
        .replace(/&/g, "&amp;")
        .replace(/</g, "&lt;")
        .replace(/>/g, "&gt;")
        .replace(/"/g, "&quot;")
        .replace(/'/g, "&#039;")
        .replace(/\//g, "&#x2F;")
}


Does MS14-066 affect CE versions of Windows?

potentially, yes. However only if the device ran a vuln service which accepts SSL/TLS certificates would it be a problem, at least at this time.

Schannel ships with all versions of CE, and the Schannel bug (there's actually several MS addressed in MS16-044) dates way back.  For example, the same issue exists in Windows XP, but will remain unpatched.  There's reverse engineering of the patch here http://blog.beyondtrust.com/triggering-ms14-066 , if you get the Windows 2003 patch, diff it against 2003 native, and then compare with Schannel in CE you can confirm yourself.


What is the scope of the NSA's backdoor in Microsoft's CryptoAPI?

With input from Aria and Xander, it appears that the RNG in question is no longer used/widely used in Microsoft production code following concerns from Microsoft developers back in 2007, and although it can still be used for applications written against CNG, the backdoor is widely known enough that it is not used either in production Microsoft code or in well-known third-party applications. Thanks for the input!


SIEM: Correlating remote logons to associate origin and target user

SIEM correlation rules generally require matching or corresponding attributes in a log in order to link 2 logs together. So one option may be to match on ip addreses. Perhaps it's a timing rule such that a remote (personal) account logs in and a log shows they are assigned an internal ip. Then the rule says that if within 5 minutes that internal ip logs into another system with a different account (technical) then report it to you. Now you have an alert that correlates the personal account to the technical account.

Example:

Log1: vpn says user1 remoted in from 8.8.8.8 & was assigned ip 10.0.0.1

Log2: Linux server says technicalaccount1 ssh'd I'm from 10.0.0.1

Alert: Linux ssh within 5 minutes after vpn login with matching ips


How to filter secure (HTTPS) websites by URL with regular expression?

Only intermediate entities (firewalls) can't see the https URLs, the remote server and your browser obviously can.

If it is a parental control system, maybe you don't need to defend against a highly sophisticated attack (here "highly sophisticated" == "can uninstall browser plugins").

There are numerous plugins for the task (example). Some of them has also a functionality to make its removal much harder.

Next to that, although you can't block an URL from an intermediate entity, but you can block whole sites. The name of the used virtualhost is visible, cleartext-transmitted since some years in the TLS protocol.


web application extracts uploaded tar files, is it vulnerable?

As long as you don't execute files contained in that tarball you're on the safe side of the fence.

As you seem to have realized, there is a potential threat (known as a zip bomb) which contains heavily compressed content which, when extracted without size checking, will use a huge amount of space on the disk.

// when you say max size you mean the size of the tar file or the size of the extracted files?


There is a lot of information you can acquire about the hardware of the computer your program is running on, including serial numbers of individual pieces of hardware (consult stackoverflow for code examples). This gives you a pretty accurate fingerprint of the system.

If you have your software "phone home" by contacting your server at startup, it can send you that fingerprint to tell you which machine it is executed on. If you receive far more such fingerprints than you sold licenses, then something is wrong.

However, this won't tell you from whom the pirate obtained their copy. You could find that out by only distributing personalized copies of your software: Include a serial number in each copy you sell. Send the serial to the server together with the hardware fingerprint. When your server receives the same serial number with a different hardware fingerprint, you know which of your customers pirated it and you can take legal actions.

But there are, of course, countermeasures the pirates could take:

Find the serial-number in your software and change it to hide the source
Use a personal firewall to block the phoning-home feature
When the software won't run without phoning home, crack the software to suppress the phoning-home feature
Crack the phoning-home feature to send false hardware fingerprints

Unfortunately there is not much you can do about this. Once your software is on hardware you don't control, it's no longer your software.

The software industry is trying to develop software-based copy protection since the invention of the floppy disk. So far they haven't succeeded in creating a solution which withstood serious cracking attempts from the piracy community, despite investing millions of dollar and using some ethically questionable methods (like modifying the users operating system).

I am also a software developer and I have come to the realization that there are really only two ways to make money with consumer software:

Method 1: Tie your software closely to a subscription-based online service. Consider the service your actual product and the client software a free tool to use it.

Method 2: Simply accept that only those people who really want to pay for your software will pay for it and the rest of the world will pirate it.


Is it safer to use a PGP key encrypted with a password than just the same password separately?

depends on your key length, but think of a key as the first "long"(hashed) version of your password (used in proper used cryptographic that is) so, in short its impossible to answer.

But when used with a appropriate long key file, it can be a lot more secure than a password.


You are correct.

That's why you should also use SSL, choose your VPN location/ISP wisely, or even use a mixnet.

Any good web based encryption or secured medium (HTTPS,SSL,TLS,SSH Tunnel,etc) will protect the URL and content,however the ISP will still know where you connected to (ie. they'll know the VPN node you're connected to, not the end destination).
If you choose your ISP wisely you can evade data retention (e.g. in Austria only ISPs who reach a certain annual turnover have to implement data retention (unless you are not worried about 3-letter-agencies eavesdropping somewhere between your ISP and the server).
If that's not enough, you can use https://www.torproject.org but there are a lot of things you can get wrong when configuring it (you might still reveal your identity to the exitnodes, they might try to DO MITM, etc.) You will find all the information you might need on their website though.
If data contents going through the ISP have to be concealed, you do not need to use an expensive VPN. SSH tunneling through a random rented shared server or using a trusted & encrypted session to a proxy work just as fine. Research on SOCKS5 proxies for example.

Did this answer your question?


Is there a risk to a business that is using a shared certificate?

It is a certificate of a content delivery network – a U.S. company Incapsula Inc. – intercepting your whole communication with the bank. The certificate itself does not pose a direct risk to customers' data, but:

  Is this considered a bad practice?

Unlike the other answers, I would say it is not normal and the situation indicates a certain level of incompetence on the bank's side.

According to Incapsula's pricing plans, your bank might be using $59/month, while the company offers custom SSL for $299/month (feature "Supports custom SSL certificates") and a real plan for enterprises.
Even if the bank pays more to CDN, the bank is using functionality aimed at professional blogs and not using the features their plan/agreement offers.
Your bank may be violating privacy laws in your country by letting a company from another country, under a different legislature, process customers' personally identifiable data.

  What risks are their customers are subjected to? (man in the middle? impersonation?)

The data in a encrypted between your browser and the CDN's endpoint. The private key is (hopefully) stored only on CDN's servers, so there is no risk other companies from the list could impersonate the bank.

As long as security standards are met on a link between CDN and the bank, the MitM is technically not possible either.


Why are static password requirements used so frequently?

After the famous XKCD strip, there were a few projects started up to deal with exactly this kind of entropy checking. One of these was the ZXCVBN password checker, made by a Dropbox employee.

It is possibly the most thorough password checker of its kind. It checks for patterns, words, and more, adding to (or subtracting from) an entropy score accordingly. It is explained in detail on their blog.


Referencing Software Standard Risk Severity List?

Establish your own standard of risk ranking, and get your client to agree to it.

Start by assessing the risk that the app poses to the organization. For example, if the system handles any regulated data (PCI, HIPAA, GLBA, PHI, PII, etc.), or if it is externally facing, or if it is mission critical, call it a high risk system, and anything the pen testers find will be classified as a high risk finding that must be addressed immediately. But if it's not a high risk system, then only demonstrably exploitable findings will be considered high severity vulnerabilities that require immediate remediation. Perhaps you can further identify a class of "very low" risk applications that can be exempt from costly pen testing.

Your clients only have so many security dollars to spend.  It's your responsibility to help them spend them where they have the best chance of producing meaningful results.


Can CloudFlare be DDoS-ed and issn't the actual DDoS mitigation limit, financial resources?

I work for CloudFlare so maybe I can shed some light on how we do things.

Fundamentally, CloudFlare uses an Anycast network design; this means that network traffic has no control to where it is routed and it is automatically routed to the closest available host. Computers compromised by botnets are typically distributed throughout the world in different geographical regions. Because of using an Anycast network we increase the surface area of our network such that it is harder for a distributed attack to take us down. The traffic cannot merely overwhelm a single datacenter, in order to grow out this protection we now have 86 data centers around the world and we plan to add more.

We also operate an open peering policy where we are willing to directly interconnect with ISPs (PeeringDB). By removing the middle-men we are able to have the shortest path from the source of the attack to where we can filter the attack. Today, we have the single highest participation in Internet Exchanges globally, of any network. By having a direct path form attacker to destination we can prevent collateral congestion on our network.

Yes, we need a large network to come with attacks, we need big pipes so people can't congest them - to that end our network is 96% bigger than the largest DDoS attack ever recorded.

This is despite the fact we have seen a whopping increase in attacks. There are some interesting characteristics about these attacks; they predominantly happen on weekends (attackers busy with something else on the weekday?), they happen against largely benign websites indicating that anyone can become the target of an attack and also these attacks are massive in capacity.

Almost all of our Layer 3 attack handling is now autonomous, we use a range of strategies to protect against attacks. When attacks come to our Edge we have worked out strategies in order to ensure we are able to reduce the impact of such malicious traffic; we then seek only to pass on safe traffic to the origin.

In many ways CloudFlare has become the DDOS filtering method of last resort; for Business and Enterprise we have advanced protections against DDOS attacks backed by a full SLA, we offer this at a flat rate to ensure that DDOS attacks aren't successful in bankrupting their victims. For at risk public interest sites we have Project Galileo offering this technology for free to those public interest websites who need it.

Currently one of the largest risks to the internet lies in open DNS resolvers, which can be used for DNS amplification attacks by hijacking insecure DNS resolvers; I would highly recommend looking at the Open Resolver Project to learn more. Finally, an article from about 3 years ago on our blog goes into detail about how the DDOS attack against Spamhaus almost broke the internet.


You do know that Truecrypt is also free and open-source, right?

Aside from commissioning independent testing, the only assurance you are likely to get is from users/hackers discovering issues and publishing them on the web, so your first port of call should be a google search for Diskcryptor advisories

Number of advisories published can be a reasonable indicator of development quality, when considered along with usage numbers - obviously a product with large numbers of users could be expected to have more issues reported than a less popular one. Alternatively, look at the documentation on their development and testing processes - or their bugfix revisions.

Finally, you could look into the authors of each tool and see whether you can place some reliance in their work.


How can I test that I have correctly disabled unnecessary HTTP methods?

@Owen nailed it, but just to show an example of doing it yourself:

$ telnet localhost 80
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
TRACE / HTTP/1.0

HTTP/1.1 405 Method Not Allowed
Date: Tue, 19 Nov 2013 12:11:40 GMT
Server: Apache/2.2.22 (Linux/SUSE)
Vary: accept-language,accept-charset
Accept-Ranges: bytes
Connection: close
Content-Type: text/html; charset=iso-8859-1
Content-Language: en
Expires: Tue, 19 Nov 2013 12:11:40 GMT

The TRACE / HTTP/1.0 is what you type, followed by two newlines.  The first line of the response (405 Method Not Allowed) tells you that the web server doesn't accept TRACE.

Knowing how to form a request of the different methods can be difficult if you don't already know HTTP; the OWASP project has some examples on how to Test HTTP Methods which can help you.


Certificate validation to multiple Root Certificates?

I suspect, you are talking about SSL/TLS certificate validation in a HTTPS context.

  how can a server know which Trust Anchor the Client has, as in which RootCA to indicate for the Path-Validation?

server don't know and not required to know about trusted anchors installed on the client. Server sends leaf and intermediate CA certificates (without roots) and the rest is up to client.

Client uses retrieved certificates and constructs certificate chains. During certification path building multiple chains can be produced (due to cross-certification). That is, leaf certificate has more than one path to one or more trusted anchors. Depending on on client configuration (crypto library), only single chain (best one) is chosen and used for the rest process of certificate validation.

Eventually, there might be a case that chains on server and client are different. For instance, server has Root A as a trust anchor (but no Root B), while client has Root B as a trust anchor (but no Root A). If intermediate certificate can be chained to Root A on server and to Root B on client, the certificate will be successfully accepted.

  Does any answer change if Root A and Root B both have the same Subject?

they have to have the same subject, because one of certificate binding in the chain rules is that issuer field of the certificate must match the Subject field of the issuer certificate. Otherwise, the issuer certificate may not be found.

  Will a client accept my Cert if it has only a self-signed Version of intermediate (but same priv/pub Key and Subject) as Trust Anchor?

if crypto library does support use of non-self-signed certificates as a Trusted Anchor (Microsoft CryptoAPI, for instance, does) then it is possible. Then root certificate has no effect in the certification path building.


Supposing the rule is already in a Snort .rules file and snort.conf is configured to include the .rules with the rule to test...

$ snort -r foo.pcap

...or...

$ snort --pcap-single=foo.pcap

...from...

http://manual.snort.org/node8.html


Which is more secure - a VPN, a proxy-server, Tor, etc.? And why so, exactly?

You ask about services, tools and concepts in one question.

All this could be used together, sometime one by another:

You could implement a proxy server to re-routing all you web traffic via Tor, for sample.

I think you have to invest (our time) to ensuring your understanding.

A proxy-server is a tool installed locally or remotely, but installed in one server, to re-serve web pages.
A VPN is a concept that could be implemented by using a lot of different ways (IPSec, OpenVPN, SSH, ...)
Tor is unique, it's an entity (like Facebook, but not with same goal). They use a lot of tools and concepts, like proxy servers and VPN.


As Matthew said, you can directly set the cookies with the document.cookies="..." command in your browser console.

Example on security.stackexchange.com:

As you can see, I am not logged in. I cheated a bit and directly retrieved my cookie through my browser, and not through wireshark, but your question is about setting it once retrieved.

Cookie Name  |  Value
acct         |  t=7c6483ddcd99eb112c060ecbe0543e86&s=080f651e3fcca17df3a47c2cecfcb880

To set it, you can use the document.cookies="{COOKIE_NAME}={VALUE}" command, like I did on the picture above. You need to repeat this command for any cookie you want to set.

I just need to refresh the page, and the cookie will authenticate me.

Here, the Storage tab shows the cookies that have been set.

Note that other security controls may be put in place to prevent cookie theft, like checking other information associated with the user. (Browser, IP, etc.) It is the case here, I couldn't do much before being deauthenticated.


Disclosure of end user files or installation of Trojan horses via XSS

An XSS attack could replace a legitimate download link on the site to one that contains a trojan. The user clicks the link, downloads the executable and runs it thinking it was the genuine program they were intending to install. The attacker could even backdoor the original executable so the user doesn't suspect that anything is wrong.

As for user files, it is not clear from the article but I'm assuming it is files uploaded to the system in question, not the user's file system.

So while an XSS attack doesn't allow actioning these things directly, should the user be unaware that an attacker has access to the client-side of their session, then the specific attacks mentioned could be accomplished.


Using client certificate to authenticate an app

I don't want people to send random requests to it using wget or anything similar. [...] Every copy of the app will have the (same) client certificate bundled with it.

Ok, that's a bad idea. It won't work. Roughly summed up: if a secret value is copied into more than two places, then it no longer is a secret. In that case, if some people have any interest in "sending random requests using wget", then they just have to extract the certificate and private key from any copy of your application, which is a trivial bout of reverse engineering.

Think about it: if hiding a secret value in a widely copied application worked, then there would be no possible DVD ripping. Music editors would not wail and grind their teeth at the thought of software-based piracy. There would be no cheating in online games.

The usual catch-phrase used to describe this situation is: client-enforced security does not work.

Mind the context, though. Extracting a private key from a compiled application that uses that key is not hard; however, that does not mean that people will do it. Apathy is one of the strongest forces in the computer universe. Such reverse engineering will happen only if somebody, somewhere, becomes motivated enough to invest a couple hours of his time (at most) on that task. This may happen only if there is anything to gain in, indeed, "sending random requests with wget" to your server.

Many weak systems, even applications which try to enforce client-side security, fail to be attacked simply because nobody bothers to do it.


Strategies to store/remember very long password?

The virtue of a password is to make it possible for humans to remember it. If you want to store the password, then you are not talking about remembering; at which point you may forget this "long passphrase" business, which becomes just a nuisance. Store a random key which needs not be that long (16 bytes will be plenty in practice, the ultra-paranoid will go to 32 bytes, aka 256 bits, which is provably total overkill).

Also, a long verse from the Bible is a very poor passphrase because there are about 31000 verses in the Bible, thus making 31000 possible passphrases -- less than 15 bits of entropy, which is pathetic. As usual, it is not length which matters, but randomness; not what the password is, but what it could have been.


Most secure response for a server to return to a user scanning for exploits

The problem is that you may have vulnerabilities in your system. Scans are unavoidable.

Scan your own site and make sure you are immune to such low hanging fruit. Pay an application penetration tester to make sure you are immune from more threatening attacks. Use a web application firewall like mod_security to filter attacks before they hit your web application.


Dealing with a fraudulent email that went to vendors

The experience your organization has had is similar to what many organizations that deal with sensitive information deal with on a regular basis (ie banks, credit bureau's, revenue agencies, etc). Whale Phishing in particular is a nasty attack that takes advantage of these technical weaknesses.

This issue is one that mostly needs to be solved with procedures, as opposed to technical controls. Below are some examples, but these are obviously not completely fool proof nor do they apply to every situation.

First and foremost establish internal policies and procedures when dealing with any movement of money or sensitive information (Wire Transfers can only be initiated by in-person meetings, orders must be processed after sign off from two people that are in the office, etc) and ensure these are adhered to. This means ensuring that everyone affected internally is aware of these policies and adheres to them.
Issue communications to relevant stakeholders letting them know that specific communications (such as account breach in the case of banks) will never come from e-mail, or your organization will never request you provide information from links contained within emails.
You may choose to register domains that may slightly vary on what your domain is to prevent cyber squatting (ex d0main.com / doma1n.com).
Establish an email address or phone line that people can call to inquire about the authenticity of an email transmission (ie abuse@domain.com)
Put a statement on your website to let relevant parties know of your policies.

It's not exciting but the best way to mitigate these attacks is to establish a firm set of policies and communicating those policies to whoever would need to know them. Let your vendors know that that you'll only place orders through their secure portal (for example).


Should I scan both HTTP and HTTPS seperately?

Technically, it is entirely possible for a web server to return different content depending on whether you accessed it via HTTP or HTTPS. In fact, nearly all servers supporting HTTPS do this; if you access /foo/bar via HTTP, you get a redirect to HTTPS, and if you access it via HTTPS, you get page content (or at least a 404). It's rare (though not unheard-of) for this redirect to itself have a vulnerability, so it's worth testing. Additionally, it's a good idea to know what content your web server makes available over plain HTTP - sometimes sensitive data is exposed! - and also some web apps will send a user from HTTPS to HTTP for some links/requests and that gives a network attacker a good opportunity to steal cookies, data, or begin an SSL-stripping attack; you definitely want to find such things.

Pretty much the only time that you can completely ignore plain-text HTTP is if you use HTTP Strict Transport Security (HSTS). A user visiting the site for the first time will presumably neither be sending nor receiving sensitive data in their first request/response, and will be immediately redirected the HTTPS and then the browser will not allow any further HTTP requests to that domain once it sees the Strict-Transport-Security header. Some very old browsers don't support HSTS, but... well, anybody using a browser that old is metaphorically wandering around picking up random guns, aiming them at their foot, and pulling the trigger; it's not your job to try to stay ahead of them and unload every gun they might find first.

Scanners generate so many requests already, and HTTP->HTTPS redirects are so light on server resources, that I don't expect you have any need to worry about extra scan time or server load. Scanners are generally "smart" enough to not bother with HTTP requests when every time they try one they just get a redirect in response, when they see HSTS headers, and/or when all cookies are set with the Secure flag so somebody using HTTP instead could only make unauthenticated requests.


Securing my USB flash drive with Truecrypt and FreeOTFE

Using more than one layer of encryption adds more complexity and very little security.

Modern encryption ciphers rarely suffer catastrophic failures but software implementations are not that perfect. Using multiple disk encryption tools may decrease your risk in case one of them will have a known flaw or backdoor that will make your stored data vulnerable. By the same line of reasoning, running multiple encryption tools increases the risk that one of those tools might have an active backdoor or exploit that would compromise your whole system including the data you want to protect. That backdoor might be placed by the author or by attackers breaking into the author's computer or the website that servers the tool. Even the act of downloading (multiple) encryption tools might put you on the list of suspicious citizens (in some countries) or interesting targets (you have something important to protect).

The overall confidentiality of your data depends on many factors, not just encryption. Focusing on doing one layer of encryption right provides most of the security encryption can provide. The effort of using multiple encryption levels can be directed to improving other factors such as physical security, computing environment security (OS, Browser, etc) and key security.

Reducing the complexity of your whole system and managing the overall risk is the right mentality.

And remember, encryption is both a blessing and a curse for security.


Is my Google session safe when my computer is logged out or locked?

If your hard drive wasn't encrypted, someone could access your hard drive and view the cookies used for authentication, and bypass 2 factor.


In that case -

Client credentials would need to be sent with every request to every server-side app/system that can present resources.
There would be no expiry and no scope limitation on any specific session.
It would be just like legacy basic auth, with all its drawbacks and benefits (simplicity)

In the OAuth client credentials flow, 'client' refers to a client application and not necessarily the resource owner (end user).  In some cases, like mobile apps, both are almost the same, as there is usually a single user of the client.  Thus, for a simple application, replacing an access token by repeatedly sending client credentials may be a suitable substitute.  However, for any distributed application where APIs and resources are distributed across different domains/servers/applications, having a central token endpoint is more scalable and more secure just by virtue of being a single point.

While Facebook has two-legged OAuth for end users (resource owners) using Facebook apps (clients), Facebook provides access tokens to Facebook apps via OAuth client credentials workflow.


Suggestion on asymmetric (hybrid encryption) encryption for big file

Not an answer but you asked for suggestions and this would be a lot for (SX) comments.

(0) openssl pkcs8 -topk8 ... -v2 aes-128-cbc -nocrypt is misleading at best if not wrong. If the output file is not encrypted, it doesn't matter what algorithm is not used to encrypt it.

(1) openssl enc -pass file: (or -kfile) reads the first line of the file as a string, and uses it as password (not key) with a weak PBKDF. You have random bytes for 'password' so the weak PBKDF is only silly not broken, but there's a 12% chance one of the random bytes will be NL or null and cause the key to have reduced entropy and about a 6% chance it will have low enough entropy to be broken. Either use rand -hex value as key with -K uppercase; or use rand -hex or convert to base64 (either of which gives all-alphanumeric) and let the PBKDF (trivially) distill it.

(2) CBC is unauthenticated and somewhat malleable (though not as bad as the stream modes) and you don't add authenticatation. If an attacker wants your device to accept an altered file, they probably can after a fair amount of work, although the details depend on your file(s) and your device(s).

(3) CBC requires padding and openssl enc uses PKCS#5, and you don't authenticate; if your device is observable, this probably gives a padding oracle. If an attacker can provide crafted files and detect whether your device successfully decrypts or not, they can quickly break your encryption.

(4) But why are you encrypting anyway? Is this firmware secret? Most firmware isn't, and in most applications where firmware is downloaded the important thing is integrity and authenticity, that is, loading only authorized firmware while rejecting tampered or forged firmware. Encryption in general is not designed to do that, and this encryption in particular does not do that. If what you want is integrity and authenticity, use signature not encryption, as @P4cK3tHuNt3R pointed to.

EDIT: specifically for authentication you can use digital signature

openssl dgst -$hash -sign privatekeyfile >sigfile
# combine the pieces for transmission then separate and
openssl dgst -$hash -verify publickeyfile -signature sigfile

or use CMS format which combines and separates the data for you

openssl cms -sign -signer certfile [-inkey keyfile_if_not_in_certfile] -outform der
openssl cms -verify -inform der [-CAfile/CApath unless your root or selfsigned is in default truststore]
# assumes the transfer process handles binary, as most do nowadays;
# if not use -outform and -inform PEM, or default SMIME with -text
# to add/strip dummy headers presuming your data isn't proper MIME

or several possible MACs, but from commandline HMAC is easiest

openssl dgst -$hash -hmac keystring
# at each and and compare
# note you can't easily use an arbitrary (binary) key here
# but HMAC construction inherently distills up to one hash input block
# worth of key so just use about 128 bits of entropy in hex or base64

openssl supports a variety of hashes, but unless you need to consider other factors I would use sha256 or sha512, the latter especially on 64bit machines. Hashes now officially broken or endangered for general signature (MD5, SHA1) would actually be safe in your application, but that can be complicated and timeconsuming to justify to people, so just avoid the problem.

If you really want encryption and authentication, although as above I don't think you need it, authenticed encryption modes GCM and CCM (which do both at once) are available in openssl library but not (currently?) in commandline, so easiest is to just encrypt and then authenticate with either/any of the above. The key (as it were) is encrypt then authenticate, and conversely verify then decrypt; this blocks the malleability and oracle that apply to unprotected CBC (and most other) encryption.


How can I safely check whether an email link leads to a malicious website?

VPN Virtual Machine View-Source for those who know Javascript

[Tinfoil Hat (Mythic Warforged)] here.

If you are handy with Javascript and the like, I've always appreciated view-source:http://www.webaddress.com/ from the URL bar. For added tinfoil, do it behind a VPN, and a Virtual Machine.

The VPN is necessary just in case the attacker expects you to visit personally from your actual IP address. Your access attempt will show up in the visitor logs, but if they just get a random VPN, then Ho Ho Howned.

And the Virtual Machine is, of course, there to prevent strange attacks against the view-source page, which may or may not exist. Will not help against VM-escaping thingmabobs. Alternatively, you can programmatically open a socket connection (be wary of vulnerabilities in your chosen language) while behind a VPN, and use GET /page.html HTTP/1.0 to grab the HTML page, and then do the same for accompanying Javascript.

Look for funny things like zzz.saveToFile(), which usually indicate a drive-by download attempt. Same with intentionally obfuscated Javascript; it should not be trusted. Keep in mind that Minification and obfuscation are two different things.

Developer Console Watching (F12)

If you are handy with web development, and you want to see exactly what kind of odd funkiness is going on without having to completely follow the script line-by-line, then you can monitor changes as they happen with the developer console. This allows you to load the results of off-site/off-page Javascript that is generated dynamically.

Temporary Folder Watching

This is assuming you're behind a virtual machine. Obviously, you would not want to try this on your main machine.

Don't forget your temporary folder, which is usually %TEMP%. With drive-by downloads, they usually start saving executables to %TEMP%. You can see if such a thing occurs when you visit a page. They can be saved as .tmp files, which are later renamed to .exe. This is usually discovered by a function that looks like x.saveToFile()

Reset your Virtual Machine when you're done

Don't forget to reset your VM's state/snapshoot afterwards. You don't want to be infected long-term.


Security seals and the "perception of safety"?

As Rook pointed out, security theatre is a big part of how consumer perception is exploited to ensure that customers believe that something is safe, without the vendor having to go through all that complicated hassle with actual security.

The TSA is a great example, but there are many others:

Extended Verification on SSL certificates are largely theatre, as the EV process does nothing to actually improve the cryptographic or algorithmic security of the transaction. If a 3rd party wants to get a certificate for the domain from a dodgy CA, they can do so without the EV and 99% of users wouldn't notice.
The design of certain enterprise-level security appliances, from a physical and interactive perspective, are often tailored to invoke images of robustness. This usually involves building the unit out of sturdy black metal, with a few blinky blue lights on the front, and putting padlocks and other such imagery on the web panel.
Bag searches at large events like concerts are largely security theatre. It's near impossible to get a few hundred people through a proper bag search process, so the staff take a quick look and let you through. More often than not, they're just trying to stop you bringing a big bottle of vodka, so you have to pay at the bar. But part of it is to make you feel safer, despite the fact that anyone could easily conceal weapons, drugs, etc. without detection.
Anti-phishing techniques such as secret images are (usually) security theatre, in that it is often either trivial for a 3rd party to steal the secret image from the site without authentication, or that the image is displayed after the user has entered their full set of authentication credentials.

At the end of the day, it's all about marketing. If a company can sell you the image of something being more secure than it is, they are more likely to get a sale because you have peace of mind.


Is it unsafe to redirect to the referer URL?

You're creating an open redirect vulnerability but no XSS flaw. However, I can't think of a legitimate use case to issue a redirect back to the referring page in the first place. At very least you risk creating a redirect loop.
Note that in other contexts it can be dangerous to allow user-controlled URLs, especially because an attacker might take advantage of pseudo schemes such as data: and javascript: to achieve XSS. E.g., printing Click me is vulnerable even if you escape quotes and brackets.
But you don't risk that a pseudo scheme ends up in your Referer header because browsers never send them. Also, a header such as Location: javascript:alert(1) is considered invalid and has no effect in any major browser.
MDN also hints at that behavior but is less verbose:

A Referer header is not sent by browsers if:

the referring resource is a local "file" or "data" URI,

an unsecured HTTP request is used and the referring page was received with a secure protocol (HTTPS).

(Source)


How hard is it to retrieve IKEv2 Server Certificate from the server?

How hard is it to download the certificate via IKEv2?

That depends on the server's configuration and the type of client authentication.

If the client has the server certificate installed and trusts it, the server technically doesn't have to send it. The client will just use the local certificate that matches the server's IKE identity to verify the signature in the AUTH payload.

If the server is not configured to omit the certificate, certain authentication methods will prevent attackers from retrieving the certificate. With both certificate and pre-shared key authentication the client will be authenticated first. The server will just respond with an AUTHENTICATION_FAILED error notify if the client authentication isn't successful.

Only with EAP authentication (e.g. username/password via EAP-MSCHAPv2, or certificate via EAP-TLS) is the server authenticated before the client (the client will not send an AUTH or CERT payload in the IKE_AUTH request, but the server will send both in its first response).

  In case a tool for that already exists, can you post a reference to it?
  In case there is no ready to use tool, how long would a programmer need to write one?

I don't know of a tool for this specific use case.  But e.g. strongSwan's charon-cmd command-line IKE client could be used with increased log levels to dump the server certificate. Another option would be to get the IKE keys (either via log or save-keys plugin) and use Wireshark to decrypt the IKE_AUTH response and extract the certificate from there.


Do we need to include SIEM hosted in the cloud in CDE scope for PCI DSS requirement..? where no CD or transacation logs are being process or managed

The cardholder data environment (CDE) is limited to the network segments storing, processing, transmitting cardholder data. Your in-scope system components are beyond this CDE as systems providing security or other services are in scope for validation - i.e. authentication, update/patch management, orchestration, anti-virus, logging, FIM.

So this means your SIEM solution needs to be validated. The system should do at least the following:

Capture the appropriate logs
Logs should be reviewed daily
The system should generate alerts
File Integrity Monitoring should be in place to protect the integrity of the logs
Log rotation/retention policies should be in place and enforced
Users of the system should be managed and monitored appropriately
The system should be maintained up to date

Either you or the cloud service provider must evidence all the above or your cloud service provider can provide evidence to show the above has already been validated - i.e. by providing an Attestation of Compliance for the scope of the service provided.


What sort of mathematical background is necessary to learn ethical hacking?

Do you need it to just run hacking attacks or simple social engineering?  No math is needed.

However, if you want to be an expert and really understand modern cryptography, you'll need to learn some rather advanced/obscure math like modular arithmetic, Fermat little's theorem, discrete logarithms, etc.  You don't need to understand cryptography to use it, but if you want to implement it, or search an implementation for flaws/vulnerabilities, you'll need to understand it.  Have a look at Handbook of Applied Cryptography and you'll see there's a fair amount of math, that likely is unfamiliar to you.

Say you know that all passwords in a system are comprised of 12 random characters (case-sensitive including special characters) (and some salt) and you have the salt+hash, and want to break it with a GPU that generates a billion hashes per second.  Is it worth trying to break?  What about if passwords were 6 random characters?  The answer from basic probability/counting/conversions is don't try with the first one (should take million years); but the second should be trivial to crack (done in under 5 minutes)?  Some security algorithms (like Microsoft's LM-HASH ) didn't recognize this basic fact that two N/2-length passwords could be cracked in ~10 minutes while one N-length password may take a million years.

Its hard to say a priori what you don't need to know; as sometimes understanding something can help tremendously,  see relevant (and today's) xkcd.  Math is also great at just teaching you to think very logically; sort of like how doing a push-up isn't very useful on its own -- but being in shape/strong from doing push-ups is quite useful.


Make sure your URL does not contain any SQL injection snippets. The URL should be valid. Also try using * on the parameter like so:http://mysite.com/test.php?id=*
Make sure your request is a valid GET request and not POST. Mixing those up can cause to miss your target.
Try using the -r flag with an intercepted request you've saved from something like burp. This way I know I'm not missing anything important. Do this if you want to test POST method requests.


Is dd-wrt generally more secure than manufacturer's firmware?

Most manufacturer's firmwares for routers are actually built around the same open source software as open source alternative like dd-wrt. The real security distinction is not between a "manufacturer" and an "open source" firmwares; it is between a maintained firmware against one that is not. A crucial element for security is how promptly fixes for discovered security holes are designed, published, and installed.

If you take a router, install dd-wrt on it, and then forget all about it and just let it run without ever installing fixes, then your security won't be better than if you had left the manufacturer's firmware in place. The bright point of dd-wrt is not that it is "more secure", but that it makes it easier to install updates, and that is what security comes from. You still have to do it, though.


How to detect and exploit an SQLi in a POST method

One of the easiest ways to do both (detect & exploit) is to download sqlmap and use the -r option.

Capture the POST request using any proxy tool, paste it into a file, then do:

# sqlmap -r <text_file_with_raw_POST_request>

(add --force-ssl switch if needed)

From: https://github.com/sqlmapproject/sqlmap/wiki/Usage


Yes, by using an intercepting proxy such as BurpSuite (https://portswigger.net/burp/).  When you setup your device to use that machine as a proxy; you can surf to "http://burp" to download the CA certificate.  This prevents you from having to do all that yourself.

When you import and install that cert, you can see the decrypted HTTPS traffic that is passing through your proxy; that is - unless the apps you're looking at perform any form of certificate pinning; then they'll stop working.


Files related/required to a digital certificate

To put it as simple as possible:

a cer is a certificate. Think: a (your) public key, signed by a CA (certificate authority)
a csr is a certificate signing request. Think:

  Here, CA, this is my public key and a proof that I do in fact have the private key for that public key

p12 is a container format that holds various things. Often, and probably in your case a key pair (a private and corresponding public key), often encrypted itself.
JKS is the java keystore format. Like p12, it is a container, which can hold multiple keys and/or certificates.  A keystore which holds only certificates is called a truststore.
DER and PEM are two different encodings used to represent a certificate.


How are Chrome and Firefox validating SSL Certificates?

Browsers and/or operating systems tend to come with a pre-defined list of CA certificates used as trust anchors to check the certificates of servers they connect to. They're all customisable (except for EV certificates, for which the root certificates are hard-coded into the browser, although you can disable them... bug excepted).

Firefox uses its own list on all platforms.

Internet Explorer and Chrome use the operating system's certificate repository on Windows. The default is available via Microsoft's Root Certificate programme.

Apple also has its programme.

Trusting an a priori unknown server certificate is done by building a certification path between this certificate and one of the browser's trust anchors. This is done as defined in RFC 3280/RFC 5280.

In addition, certificate revocation can also be checked, either via CRL or via OCSP.

  So it's not possible to intercept communication between the browser
  and a CA to fake a valid certificate as the certificate is likely
  already in the browser's cache ?

To re-iterate the point I made as a comment to Wug's answers: the trust anchors repository is not a cache. A cache is a dynamic placeholder aimed to keep what you've accessed recently at your disposal, based on the assumption you'll need them again soon. In contrast, your trusted certificate list must never be updated automatically on the basis of what you're currently browsing. (It could be updated by automatic security updates, but that's a different issue.)

The server certificate will be obtained every time a new SSL/TLS session is established, and the browser must verify it every time. It's not cached. (You could have some OCSP caching, but that's to improve performance and kept only for a short period of time. This is just for verifying the revocation status, at the time of access.)

Contacting the CA is just for certificate revocation. You don't otherwise contact a CA. CA certificates (your trusted anchors) are a given, a "leap of faith", bundled for you by your OS/browser (which you can choose explicitly, but it's fixed as far as a given connection is concerned). At best you could prevent the certificate revocation check to happen (which may cause your browser to make its validation fail, depending on its settings).


Using ssh would be the easiest, enable the GatewayPorts and Forwarding features on the Linux ssh server,  on host C run:(plink also works with the same command line)

ssh -R 0.0.0.0:3389:127.0.0.1:3389 user@linux -N

And rdp to the Linux ip.


Buffer overflows on the heap vs the stack

With a stack overflow - if you just keep overflowing - you overflow first locals vars, then saved registers, then return address, then function arguments, then stuff further down the stack, maybe exception handlers, etc.
Usually as an attacker you indeed use the overwritten return address to jump somewhere interesting.

With a heap overflow you overflow ... whatever lies beyond your piece of memory. In old or bad heap implementations that might be heap metadata that can give you e.g. the power to write stuff into memory (which you could use to overwrite a function pointer). In other heap implementations you will have to engineer a pattern of allocations and deallocations to get the heap into a state where there is an interesting allocated piece to the right side of your piece of memory. Maybe a vtable or some other function pointers.

Heap overflows are highly specific to heap implementation and application. On linux there are the „house of ...“ techniques because glibc malloc is a joke (sorry!), on windows the heap got very well secured and well randomized and you have to hope for applications to bring their own insecure heap implementations to get 1% more performance. They often do.


Why are security-crucial software written in unsafe languages?

Most software is written in languages that the developer knows how to use, and for security-related software, that's not a bad thing -- provided that the developer actually knows his language of choice, down to the fine details, and I may argue that this is not the case with C and C++ (a vast majority of developers who believe they know C or C++ are actually wrong).

On Unix-like systems, in particular Linux (where a substantial part of all open-source development occurs), C is "the" system language. Unix is very C-friendly (all low-level API are C-based, described with C headers; system libraries are written in C, so the C compiler is well tested and well integrated). This has resulted in a large C-based ecosystem where developers use C because they know C and want to use libraries which offer a C-based API. This has nice portability benefits (for instance, no problem in running OpenSSL on a PowerPC or a Mips -- try doing that with Java !).

Using another language entails some issues: lack of runtime support, less portability, an assumed lack of performance... ("Safe" languages can be efficient, but some widespread implementations will be either slow because they use interpreters with no JIT or will be memory hogs; and also many people just dismiss these languages as inherently slow because they did not actually tried, and they think in slogans).

This leads to my conclusion: people use C and C++ for security-critical software out of tradition.

(I write all that as someone who wrote his own Java VM to run a SSL server written entirely in Java, on a small 50 MHz PowerPC system with 16 MB of RAM -- it was a Certification Authority, and it could serve 70 clients simultaneously. So when I say that a "safe" language like Java can be used to run security-critical software on low-power systems and with decent performance, I mean it.)