If you setup a similar environment within a VM its very unlikely that the remote controller could break out of the VM into your main machine.

If you are running as an unprivileged user, the remote user may only have those privileges. I suggest at the very least only running the program as a limited user with the ability to change outlook settings. Otherwise, he has complete control of your machine. Depending on how the software is written, the controller may or may not be able to hide actions from you. This is horrible security wise for you and I would rather take it to help desk in person and watch them work, or only let the person do his work in a VM, then mirror the settings on your own on your machine.

You are giving this person complete control over your computer.

Honestly doing all of your work within a VM has its benefits, such as being easier to backup, and being able to recover from just about anything through snapshotting.


How to stop app from fetching data from my website?

If some server backend for the app is sending the requests

As I understand it, the requests that fetch data from your website are comming from a server that works as a backend for the offending Android app. You have a number of possibilities:

Block the IP of the server. This may end up being a cat and mouse game if they change the IP, so not the greatest of solutions.
Rate limit on IP. The server will be making loads of requests per hour, so you could probably set a limit what would not affect ordinary users.  I would say that this is the most promising solution.
Limit how many active sessions there can be for the same IP. Note that there are legitimite cases where you have more than one session on the same IP, such as multiple users logged in from the same corporate network.
You could check that the User-Agent looks like a browser. Easy to circumvent, but much like a fence does not keep a thief out it still clearly demonstrate where the property line is.
If your website is more of an API, you could use some other custom HTTP header that valid requests must use. Same limitations as the above point, though.

Access-Control-Allow-Origin and similar is of no use here, since they regulate what requests browsers are allowed to make. It's not relevant when a server is making the request.

If a browser, or something following SOP, is sending the request

The same origin policy prevents sites on one origin to read the responses from requests to another origin, unless the server the request is directed at has been explicitly configured to allow this (via CORS).

Your website is one origin, whatever the browser in the app is displaying is another origin. So this should be blocked by default.

If the app is sending the requests

If this is the case, you are in trouble. You could try the last two bullet points from above (User-Agent or custom HTTP header), but they can be easily circumvented. So you might be out of luck here.


Wiping magnetic stripe on card with magnet?

With a weak kitchen magnet this can take many passes and a fair amount of time. In fact if all you have is a fridge magnet you may be better off scraping the strip off. However a more powerful magnet can erase the card fairly quickly. See http://www.creditcards.com/credit-card-news/video-magnets-make-credit-card-mag-stripe-not-work-1457.php for details. Whether or not, with heroic effort, some of the information can be recoverable is open for debate.

Now for a personal anecdote not involving household tools. I used to work at a lab with NMRs (Nuclear Magnetic Resonance). These have incredibly powerful magnets, in fact there are circles on the floor showing the closest you may approach with any metal. If a researcher forgot to take off their ID card or credit card and entered the room then they would need a new card as the strip was demagnetized.


Amount of simple operations that is safely out of reach for all humanity?

As a starting point, we will consider that each elementary operation implies a minimal expense of energy; Landauer's principle sets that limit at 0.0178 eV, which is 2.85×10-21 J. On the other hand, the total mass of the Solar system, if converted in its entirety to energy, would yield about 1.8×1047 J (actually that's what you would get from the mass of the Sun, according to this page, but the Sun takes the Lion's share of the total mass of the Solar system). This implies a hard limit of about 6.32×1068 elementary computations, which is about 2225.2. (I think this computation was already presented by Schneier in "Applied Cryptography".)

Of course this is a quite extreme scenario and, in particular, we have no idea about how we could convert mass to energy -- nuclear fission and fusion converts only a tiny proportion of the available mass to energy.

Let's look at a more mundane perspective. It seems fair to assume that, with existing technology, each elementary operation must somehow imply the switching of at least one logic gate. The switching power of a single CMOS gate is about C×V2 where C is the gate load capacitance, and V is the voltage at which the gate operates. As of 2011, a very high-end gate will be able to run with a voltage of 0.5 V and a load capacitance of a few femtofarads ("femto" meaning 10-15). This leads to a minimal energy consumption per operation of no less than, say, 10-15 J. The current total world energy consumption is around 500 EJ (5×1020 J) per year (or so says this article). Assuming that the total energy production of the Earth is diverted to a single computation for ten years, we get a limit of 5×1036, which is close to 2122.

Then you have to take into account technological advances. Given the current trend on ecological concerns and the peak oil, the total energy production should not increase much in the years to come (say no more than a factor of 2 until year 2040 -- already an ecologist's nightmare). On the other hand, there is technological progress in the design of integrated circuits. Moore's law states that you can fit twice as many transistors on a given chip surface every two years. A very optimistic view is that this doubling of the number of transistor can be done at constant energy consumption, which would translate to halving the energy cost of an elementary operation every two years. This would lead to a grand total of 2138 in year 2040 -- and this is for a single ten-year-long computation which mobilizes all the resources of the entire planet.

So the usual wisdom of "128 bits are more than enough for the next few decades" is not off (it all depends on what you would consider to be "safely" out of reach, but my own paranoia level is quite serene with 128 bits "only").

A note on quantum computers: a QC can do quite a lot in a single "operation". The usual presentation is that the QC performs "several computations simultaneously, which we filter out at the end". This assertion is wrong in many particulars, but it still contain a bit of truth: a QC should be able to attack n-bit symmetric cryptography (e.g. symmetric encryption with a n-bit key) in 2n/2 elementary quantum operations. Hence the classic trick: to account for quantum computers (if they ever exist), double the key length. Hence AES with a 256-bit key, SHA-512... (the 256-bit key of AES was not designed to protect against hypothetical quantum computers, but that's how 256-bit keys get justified nowadays).


Private Key and Public Key Serial Number and Thumbprints

Keys and serial numbers are all properties of x509 certificates. Neither private keys not public keys have serial numbers.

However, matching a public key against a private key is surprisingly simple, since the private key contains the public key.

Specifically, both the private key contain a "public Exponent" (usually 0x10001 [65537]) and a "modulus" (a 2048-bit number for 2048-bit keys, typically written as a string of hex bytes).

Since the public exponent is the same for just about all rsa keys, what matters is the modulus. If the modulus on the public key is the same as the modulus on the private key, then the keys match.

In fact, you can take the private key alone and construct the public key just by saving out the modulus and public exponent; that's all there is to a public key. Since the x509 certificate always contains the public key, you're guaranteed that the x509 cert will therefore contain the appropriate modulus and exponent, which you just need to to match with your private key to verify that you have the right one.


Can I trust that the Java CVE's contain only the affected versions?

In the quote you added:

  Vulnerability in the Java SE, Java SE Embedded component of Oracle Java SE (subcomponent: Networking). Supported versions that are affected are Java SE: 7u221, 8u212, 11.0.3 and 12.0.1; Java SE Embedded: 8u211.

Added emphasis is mine. You can be pretty safe in assuming that previous updates in there are affected by the vulnerability in some form. If a version of Java is not supported, then Oracle is not going to dedicate resources to test exploits on them.


From my limited time researching the website it seems to be legitimate in respect of its intention. It offers no downloads from any source, it currently has tracking cookies Cloudflare's and a PHP session. Also, a counter js script that is going to fc.webmasterpro.de which is strange but not dangerous.

Here is the GITHUB: https://github.com/browser-update/browser-update/

It seems to have very active contributors, I would most likely assume its a new site given its new SSL cert from Cloudflare flexible certs being dated the 20th of Nov.

My verdict is don't download anything from there but otherwise, it looks safe to me.


Does a TPM replace the default device's security, or add to it?

There is no single source of randomness on a device and there is no single way to create randomness, i.e. it is specific to the OS and maybe the OS version and maybe the OS configuration and maybe even the specific application. See for example TPM to feed random number generator for how to add (not replace) the TPM random generator as a source for randomness provided by /dev/random in Linux.


Password manager: master password or not?

The question of keylogger is a bit out of way with password managers, because once you operate on already compromised system you are not save with basically any operation, some trojans may steal data from forms in the split second managers enter it, they will also most likely save everything you have in your clipboard. Other attack vectors may be taking the password from screenshots...

Basically no password manager can help you if you are on a compromised system, because attacker doesn't need to rely on separate authentication, he can just use you. Compromised system isn't an attack vector a password manager can protect you from (and they aren't designed to).

For the question of which authentication, best option would be a two-factor authentication with password and a confirmation on a separate device, but as most managers won't let you add new device without separate authentication you should be decently safe with a single master password (of course not reused anywhere else...). Biometric authentification on usual user devices isn't very secure, so I wouldn't rely on that in front of a long and secure password.


What type of authentication should I use, basic or digest?

Basic authentication - is login and password encoded by BASE64 function. Almost same as if you transfer tham in plain-text.

Digest - based on md5 function. It's will not give password to leak.

Allways prefer to use Digest over Basic authentification

Liks:

https://en.wikipedia.org/wiki/Basic_access_authentication
https://en.wikipedia.org/wiki/Digest_access_authentication


Will PGP signed email be blocked in China?

I don't think it would -- at least not any regular person who isn't already under a watchful eye of law enforcement. China doesn't block encrypted communication, it just makes it inconvenient for people to use (e.g. you can use https when accessing non-Chinese sites while in China, it's just throttled to all heck, in the hopes to force you to use cleartext protocols). China's mass-filtering program is not really aimed at individual users, as much as it attempts to limit access to "undesirable resources" (pornography, anti-Chinese materials, etc). I've sent PGP-signed email to people in China on a routine basis (we host a few servers in Beijing, so I communicate with support staff all the time), and at no point this was any cause of problem.


What's are the advantages of L2TP/IPSEC over plain IPSEC?

L2TP/IPSEC wraps a simulated data link layer in IPSEC. Plain IPSEC just encrypts the network layer.  If you want hosts to think they're on the same LAN, use L2TP/IPSEC; if you'd rather skip the extra bandwidth and processing overhead, use IPSEC.


Scope for information security in 2yrs down the lane?

Getting a job in infosec working with a company like HP is a big opportunity. HP are about to split into two organisations, HP ink and Hewlett Packard Enterprise (HPE). HPE are making a massive push into security and want to be taking on the likes of Dell SecureWorks and Deloitte in the next few years, so as far as security goes they are a good company to be with right now.

Really you need to ask yourself is, will completing the course will help you get a better job? Another question you should ask is, are you able and competent do the job without any further education? I had a similar dilemma myself recently, I had to choose between a job in infosec and a PhD...I picked the job.


Billion Laughs Attack (XXE) - how does it work

To clarify DarkMatter's answer, it more specifically targets a programming construct called recursion.

The XML document tells itself to recursively include the entity before it. Thus infinitely looping while allocated data for the element it's referring to in the XML. This is what recursion looks like:

When the XML interpreter reads the XML, it doesn't ever get told to stop, which causes the CPU resources to become totally drained, RAM becomes full, and either the software or the operating system will crash depending on which level the XML is being interpreted at.

Edit: another interesting way to think about recursion is to visualize looking through a mirror at another mirror. They reflect eachother infinitely, that's what is happening with the data. See below for cool pic:


A DNS sinkhole like pihole (https://pi-hole.net/) just filters DNS requests from your internal network clients and silently blocks those requests that are for undesirable sites; it is NOT a honeypot. It is essentially invisible: just returning "domain not found" for blocked names. Many people use them as ad blockers, or to prevent access to various kinds of "undesirable" destinations.
A do-it-yourself setup like pihole can also improve DNS performance by serving as a local cache, only passing request up to a public DNS server when necessary. DNS filtering is also available as a service from places like OpenDNS (https://www.opendns.com/setupguide/#familyshield), or is an option in many home internet routers.


see if the below code provides a fairly significant level of security

It's difficult to give suggestions when it's not clear what kind of attacks you're trying to protect against.

My answer is that these settings would be annoying.

  $_SERVER['HTTP_REFERER'] !== "http://server.com/somePage.php"

This would prevent people from bookmarking your website effectively. It could also be a denial of service vector if someone uses Cross Site Request Forgery to redirect your users to this page with the wrong referrer; effectively logging your users out each time they visit a poisoned page.

  $ip !== $_SESSION['ip']

This would make it difficult to use your site in conjunction with an anonymity network such as Tor. Nothing is more annoying that getting logged out every 10 minutes because your IP address "changed".

  $time - $_SESSION['time'] > 5

This is very much subjective. It is really down to the user to protect his computer if he leaves it unattended, you don't know the user's real life situation.


If you talk to 1000 persons and use pre-shared symmetric keys, then you have to remember 1000 secret keys. Secret key storage can be hard. With asymmetric encryption you just have to remember only public keys, and that is easy because public keys are public, so they can be "remembered" by being published somewhere, where everybody can see them.

Moreover, you talk to machines more often than you talk to persons. In particular every time you visit an "https://" Web site. How would you, precisely, read a key over the phone with a server ? It is a machine, it has no voice that you would recognize.


To be explicit: dumping anything out of LSASS is completely unsupported and is not ever taken into consideration when building LSA protection features.

What is taken into consideration is the public APIs that 3rd parties can use to load packages into LSA for Single Sign-On support. These APIs have been around forever and many ISVs have built genuine packages for their own software. Software like smart card middleware.

The way PPL works is by limiting what foreign code can be loaded into the LSA process by checking if the code is Authenticode-signed. It must have a special key usage and signed by a Microsoft CA before LSA will load it under PPL. So third parties can build packages that work with PPL, it's just effort on their part. Turning this requirement on overnight breaks that potentially mission-critical software and that's bad.

Requisite warning: when enabling PPL also enable HVCI for protection from potential kernel bypasses.


Why is storing passwords in version control a bad idea?

The way I see it, not storing passwords in Git (or other version control) is a convention. I suppose one could decide not to enforce it with various results, but here's why this is generally frowned upon:

Git makes it painful to remove passwords from source code history, which might give people a false idea that the password was already removed in the current version.
By putting the password in source control, you basically decide to share the password with anyone who has access to the repository, including future users. This complicates establishing roles within a developer team, which might have different privileges.
Source control software tends to get pretty complicated, especially "all-in-one" systems. This means that there's a risk this system might eventually get compromised, leading to password leakage.
Other developers might be unaware that the password is stored and might mishandle the repository - having keys in the source means that extra care would have to be taken when sharing the code (even within the company; this might create a need for encrypted channels).

I cannot say that every pattern related to infosec is good, but before breaking them it's always a good idea to consider your threat model and attack vectors. If this particular password got leaked, how difficult would it be for an attacker to use it to harm the company?


Offline password managers may store your passwords in an encrypted file that can be only decrypted with a "master password". Hence, a malware would need to do one of the following:

Perform keylogging in order to spy on your master password, then find the password file, decrypt it and parse it
Read passwords from memory during runtime, when the passwords are already decrypted

This provides you with more security in the sense that such an attack is less likely to be automated.
A malware author would need to study intrinsic details about your password manager in order to perform such an attack. I argue that a widespread Windows malware is more likely to go for CryptUnprotectData, instead of targeting a specific password manager.

Regarding availability: Never ever use a password manager without an (encrypted) offline backup capability.


Pen testing - How to use credentials without remote desktop?

In addition to remote desktop (and PowerShell remoting, as @JoeM mentioned), credentials can be used for lots of things.

Accessing network shares or other resources over SMB
Access other services that are protected by Windows authentication (for example, internal web apps, SharePoint, etc.)
Logging into a user's mailbox (for example, on Exchange) to access the user's email and messaging
Using Windows remote management apps (may Windows command-line apps, such as schtasks.exe will accept a machine name and credentials)
Using Management Console snapins (many of the "Computer Management" tools can connect to remote machines)
Using Sysinternals psexec.exe tool
Using WMI (Windows Management Infrastructure)
Using SSH (if it has been enabled)
Logging into a VPN (if only Windows creds are required or you can access the other creds needed)


Does secure remote password verifier transmission need to happen out of band?

You seem to be talking about Password-Authenticated Key Exchange protocols.

But the problem you're describing is a general one: It is (currently) impossible to create an authenticated channel out of thin air. The best we have is PKI, a scheme to delegate the authentication to centralized entities which can be trusted by the client for their particular purpose, so that we don't have to explicitly authenticate each and every party we talk to.

Given PKI and thus server authentication, you can initialize a zero-knowledge mutual password-authentication within a secure channel created by server-side-authentication. Just the way that people today register accounts and passwords in an SSL-secured channel.

The difference is how vulnerable your protocol is to variety of different attacks in later stages of the transaction: Do I have a chance to capture your password in each and every login-process? What does the server and browser know at the end of a ZK-login? What is the impact of misunderstood PKI certificate warnings, assuming that the warning is caused by an active attack in 0.1% of the cases?


Recovering Data from a 1-Pass Zero'd Hard Disk Drive

There are many tales suggesting otherwise, but all of those refer to decades old obsolete technology. The net result is that a single pass write of zero, or anything else, is sufficeient to preclude  useful recovery.

Stories or theories involving magnetic force microscopes, etc., simply don't work for Terrabyte level drives. Millions of dollars of laboratory effort might recover a handful of bytes, but as a level of reference, no forensic group is going to do anything with it.

Now there is a separate question as to whether everything was zero'd (protected areas, or bad sectors), but anything written once is effectively gone.


I want to store a large number of relatively short-lived symmetric keys

The only security improvement from your scheme (over the situation where you do not apply it) lies on the following:

  An attacker would have to copy the entire file to be able to decrypt files offline.

The rest is just secondary considerations on performance issues. The core of the idea, from a "security" point of view, is that you make it difficult to obtain the whole key file through its sheer size. Indeed, there are two kinds of attacks that you worry about:

Online attacks: the attacker subverts your server, and since the server can decrypt all data files, then the online attacker can do the same as long as he maintains control of the server.
Offline attacks: the attacker grabs some data from the server and uses that to decrypt files after the attacker has been evicted from the server.

Your point is about making like harder for offline attackers, i.e. making them strictly less powerful than online attackers. I would then argue that your idea does not work well. Indeed, it is not true that the attacker would need to "copy the entire file". The attacker would need the whole file in order to be able to decrypt all files; but if he gets only 128 MB out of the whole file, he can still decrypt one file every thousands. Moreover, depending on how the attacker breaks in, "downloading" the entire key file might not be a problem for him. In particular, attackers sometime retrieve old, discarded hard disks from dumpsters: if the electronics of your disk failed, then you cannot easily wipe the contents, but a motivated attacker could recover the disk, replace the electronic board, and read the whole file. 128 GB are no bigger than 128 bytes under these conditions: that's just a disk, which fits in the palm of his hand.

There is a better solution here, which entails using some tamper-resistant hardware, e.g. a smart card or a hardware security module (the latter is much more expensive, but offers much better performance). That device will happily decrypt asymmetrically-encrypted blobs on behalf of your server, but it will never give its private key. In this setup, the device contains an asymmetric key pair (say, RSA); when a file is to be encrypted, a random symmetric key K is generated, and that key is used to encrypt the file with some symmetric encryption algorithm. The symmetric key is also asymmetrically encrypted with the device RSA public key. When a file is to be decrypted, the device is invoked to recover the symmetric key K and decrypt the file. K itself is kept in RAM only for the few milliseconds needed for encryption or decryption of the file data, and each file gets its own K.

By construction, an online attacker can use the device to decrypt files, but once offline, he has nothing left. This is a much more thorough protection system than assumptions on the alleged hardness of downloading some gigabytes from an Internet-connected server.


Is it ok to send user's private key away, even if protected with a SSL channel?

Nope.  It is never, ever OK to send the client's key to somebody else.  It's called a "private" key for a reason.


Netcat does not appear to have much bugs such as buffer overflows. Apparently it had one such bug, but a very minor one: if you invoked it as a client with a port number beyond 999999 (which makes no sense, since valid port numbers are in the 0..65535 range), then you could get a buffer overflow leading to a crash; bug report is there.

However, there is apparently more than one nc command around. On my server, which runs a pretty standard Ubuntu (13.10 currently), the nc command is provided by the netcat-openbsd package. Apparently:

The OpenBSD people decided to put a nc command in their base system, and rewrote the complete utility for various reasons, the official one being "IPv6 support" (that's a valid reason, but I suspect a case of NIH syndrome as well).
The Debian people then extracted the OpenBSD code to package it as a Debian package (which also found its way to Ubuntu, since Ubuntu feeds on Debian packages), and then proceeded to overhaul the code for reasons which are somewhat explained in this file. In particular, they claim that "the code has been massively cleaned up, and important functionality has been added". They also removed calls to strlcpy(), a non-standard function that OpenBSD people are quite fond of, but which is not part of the GNU libc that Debian systems use.

So whether a specific version has a buffer overflow is a hit-and-miss game. This is a rather simple utility; if any software may be reasonably bug-free, then that must be netcat. I suspect that if a buffer overflow is ever found in the OpenBSD implementation of netcat, then some OpenBSD developers would commit honourable seppuku.

However, there may be other security issues than buffer overflows. The main potential issue I see here is that your nc -l will run in some sort of text console or terminal, and output the bytes as they are received. Therefore, some bad guy could send control sequences which will be interpreted by your terminal. This issue is explored at length in this question.

If you run nc -l with output redirected to a file, then that problem is avoided -- as long as you take care to read the file with some tool who filters out escape sequences, e.g. a text editor.


Default or Guessable SNMP community names: public

Rapid7 have written up about this on their blog. They are basically saying that if SNMP isn't required, then it should be disabled so the attack surface is reduced, however if it is required then you should upgrade to SNMPv3 as it has security improvements:

  Confidentiality – Encryption of packets to prevent snooping by an
  unauthorized source.
  Integrity – Message integrity to ensure that a
  packet has not been tampered while in transit including an optional
  packet replay protection mechanism.
  Authentication – to verify that
  the message is from a valid source.

@Daisetsu has pointed out that only SNMPv1 and SNMPv2c use a community string. SNMPv3 instead uses an authentication key, a secret key used for authentication and a privacy key, a secret key used for encryption. (This can be seen in the RFC section 3.1, 4a and 6a).

Both these keys should be different and complex to make guessing attacks difficult, following similar requirements to those linked in the Rapid7 blog.


What methods are there of protecting a VPS from DDOS attacks?

There are many OS-level solutions to protect against application- and transport-layer DoS attacks, like SYN cookies, Apache modules, etc. However, to protect against a full bandwidth flood, unfortunately there is little you can do, as it is a function of the pipe of your VPS provider.

One good solution (which will also help you with the other kinds of attacks at the same time) is to point your domain at a DDoS-protection provider like Cloudflare: https://www.cloudflare.com/

They can basically soak up attacks of almost any size. The key, however, is to make sure that no one can determine the real IP address of your server once the domain is behind Cloudflare.


Securing iOS applications communication from client side

This belong to a more general question which could read "what can I do, as a user, to protect myself against services that have know unpatched security flaw".

The answers aren't very nice, unfortunately.

First - and perhaps the best way to handle the issue - do not use the vulnerable service and applications. This is the best possible way because not only does it protect you against your data (identity, etc.) being stolen, it also put pressure on the provider to fix their service.

Second, try to mitigate the problem: use 2FA if it is available, don't reuse password, use the service only minimally and assume every data you place it on is going to be compromised: properly planning ahead your recovery is often half the battle.

Third, try to lower the risk of interception by using a VPN to a network connected as close as possible to the target service. Unless you can connect directly to the target network, this does not remove the vulnerability but it does force any attacker to get in the route between the end of your VPN tunnel and the target service in order to exploit it.


Is adding a default context to Python's Urllib necessary security-wise? And is it enough?

Any data transmitted over HTTP is plain text and might be intercepted or read by anyone who has control of the devices/networks between the client and the server. HTTP should no longer be used for transmitting sensitive information.
Any request over HTTPS is today normally secure when using modern software and standard configuration. A modern server would refuse insecure connections, and a modern client would also refuse insecure connections.
However, a badly configured client (like older versions of Python) that don't do HTTPS certificate validation can lead to security problems. If anyone has full control over the network connection between your client and the server they might be intercepting and reading everything that is being transmitted. This is why you read that ssl.create_default_context() is recommended since it would configure older versions of Python to do certificate validation and set a recommended set of ciphers.
Not validating a certificate doesn't necessarily mean that your data is unsafe. If your connection ended up in the intended destination at the web server you wanted to reach, the connection is still securely encrypted (unless both the client and the server allows insecure protocols/ciphers). Even if someone like your ISP would try to dump the transmitted data, it would not be readable.
However, without validating the certificate you are vulnerable to man in the middle attacks if anyone in the network between your client and the web server is able to intercept your connection or by other means redirect your connection to a rogue server which can read the contents of your request (including any passwords), and pass it on to the real destination so you won't notice any thing.

If you are using an older version of Python that does not validate SSL certificates by default, and you ALSO have a reason to not trust your ISP or any network between your client and the server, you should be worried. If you are using a newer version of Python it is secure and there is no need to worry. If you are using an older version that does not validate certificates by default, but you do trust the path between your client and the server, it should probably be OK was well.

If you were using an old version of Python that does not validate SSL certificates by default, ssl.create_default_context() should be enough to validate certificates and enable a decent set of protocols and ciphers. Using a newer version of Python will automatically validate SSL certificates.

From release version 2.7.9/3.4.3, Python will validate certificates by default. This  affects all relevant stdlib modules (urllib/urllib2, http, httplib).
Sources and documentation:
https://www.python.org/dev/peps/pep-0476/
https://docs.python.org/2/library/httplib.html#httplib.HTTPSConnection


Not Secure At All
HTTPS mitigates against several threats, such as:

An attacker impersonating the server you try to communicate with
An attacker reading your communication between you and the server
An attacker modifying your communication between you and the server

However, these are all network-based attacks. On a public computer, the attacker has many ways of compromising you, (and even compromise guarantees made by HTTPS). For example, an attacker could

Install a Keylogger and wait for you to log into an account of yours
Install a custom Certificate Authority, allowing them to impersonate any server (e.g. Facebook, Google, etc.)
Install a screen recording software to spy on your private data while you view it

There are many other ways how an attacker can gain access to your data, should you choose to enter or read sensitive data on a compromised machine.


Why is the BLP access control model a mandatory one?

It's mandatory because the state stays the same while the system is in operation. Each subject and object is given a security level (clearance technically for subjects) of which cannot be altered when the system is running.

If the system allows changes of security levels then true BLP is not being practised, for example using likes of Harrison-Ruzzo-Ullman (HRU).

If your security policy allows changes then BLP is not the security model to use.


Generating passwords with rule: the contents within a 10 characters string must maintain a certain ratio of numbers and letters in no particular order

Don't generate candidates external to the cracking tool if you can help it. Instead, let the cracking tool generate the candidates for you on-chip. This is much faster for faster hashes (but makes less of a difference for slow ones like bcrypt or WPA2).

If you have complex composition requirements, you can generate a list of masks instead (which can also be used on-chip in most attacks).


Http redirect using Location, but using falsely supplied data from host header

The web server doesn't know what DNS lookup you did to get to it. As far as the server is concerned you're only ever doing something like telnet 1.2.3.4 80 GET / HTTP/1.1 host: www.wrong-domain.com
or telnet 1.2.3.4 80 GET / HTTP/1.1 host: www.mysite.com

In this context any domain in the host header is not right or wrong. The server reads that header and handles the request with a specific configuration if available or with a default configuration if not (this is what allows serving multiple domains from the same server/ip address).

Unless I'm missing something the redirect response here is not really a problem, you requested wrong-domain not  mysite and the server told you that the content you requested might exist somewhere else.

That said it is important to make sure that the default configuration on the server does what you want it to do, because a misconfiguration could leak information that you do not intend.

In this case it looks like the default configuration of your server is set to redirect all requests to HTTPS. Which is ok, but depending on what your goals for the sever are, a better way to handle it might be to have the server redirect any unknown domains to a known domain, or perhaps to just drop the connection. Thereby either reducing additional traffic to the server or at least directing it to somewhere useful.


Why would my firewall be blocking external source and external destination IP's that I dont own?

The source address that you're seeing, 235.97.144.162, is not a normal IP address, it's an IPv4 Multicast Address.  Any one of your internal systems can legitimately try to use it.  It's used for trying to join into a stream of traffic that's being sent to multiple recipients - like a television signal that all TVs can tune in to.  Your firewall isn't allowing it: that's fine; although you may be breaking some application, multicast isn't heavily used or reliably relied upon :).


How to force users on my LAN to use a specific DNS server with arp poisoning?

You are close, but there are a couple issues. Even though traffic may be redirected to your machine as a result of ARP poisoning, your socket on port 53 will not receive any packets that aren't addressed to your system, which will not be the case if clients have specified their own DNS server (i.e. your machine is on 192.168.1.x, but the packet is destined for 8.8.8.8. It will likely be forwarded and not processed by your network stack.).

To remedy this, you can use some firewall rules. You don't even need your listener on port 53 to accomplish this. Here's an example firewall rule to add to your MitM machine (or router if possible):

iptables -t nat -I PREROUTING -p udp --dport 53 -j DNAT --to-destination <your DNS server's IP address>

This will rewrite any DNS packets passing through your machine to have a destination address of your DNS server, assuming you have no other firewall rules preventing this.

Also, @SteffenUllrich is right; it is a hack to ARP-spoof your own network, and blocking or intercepting DNS is not a foolproof solution. Other protocols will still work, such as DNS-over-HTTPS or DNScrypt. The users could tunnel their traffic over a VPN or use a proxy server, or many other techniques.

Another more in-depth solution may be to restrict all outbound traffic on your network, and force users to use an HTTP proxy that you control. You'd also have to intercept TLS traffic as well, meaning you'd need to install certs on all devices.


What is the difference between double DES and 3-DES?

Double-DES is two successive DES instances, while Triple-DES is three successive DES instances.

We use 3DES and not 2DES because 2DES does not yield the security increase that you would believe. Namely, 2DES uses 112 key bits (two 56-bit DES keys) but offers a security level of about 257, not 2112, because of a "meet-in-the middle attack" which is well explained there (not to be confused with "man-in-the-middle", a completely different concept). Similarly, 3DES uses 168 key bits, but offers "only" 2112 security (which is quite sufficient in practice). This also explains why 3DES is sometimes used with a 112-bit key (the third DES key is a copy of the first): going to 168 bits does not actually make things more secure.

This can be summarized as: we use n-DES because a simple DES is too weak (a 56-bit key can be brute-forced by a determined attacker), but in order to really improve security, we must go to n ≥ 3. Of course, every additional DES implies some computational overhead (simple DES is already quite slow in software, 3DES thrice as much).


Why is 'avast! Web/Mail Shield Root' listed as CA for google.com?

The whole goal of HTTPS is to prevent eavesdropping so that anyone monitoring your web traffic can't see what you're sending. As useful as it is, HTTPS presents a bit of a problem to antivirus software because when you visit sites over an encrypted connection, your antivirus software cannot see what sites you're visiting or what files you're downloading, at least until the download finishes. This presents a risk because if you download a virus, the antivirus software won't know about it until the download is finished and the virus is already saved to your hard drive, allowing criminals to bypass the "live defense" features of AV by simply hosting the malware on an HTTPS site.

The solution that many antivirus programs use is to install its own SSL certificate as a root certificate so that it can essentially man-in-the-middle all HTTPS traffic to scan for malware. I'm guessing this is what avast! is doing.

Whether this behavior presents additional security issues is debatable but I don't think it's something you need to be deeply concerned about - after all, your own antivirus software is doing the man-in-the-middling, not a malicious party. If it worries, you, you can disable this behavior - go to Settings>Active Protection>Web Shield>click on "customize" and tick the box next to "Disable HTTPS scanning." If you do this, avast! won't be able to proactively block malware on HTTPS sites.


Kerberos has multiple mature, interoperable implementations on major platforms with active user communities and under continuous development (MIT Kerberos, Heimdal, Microsoft, Java), and through standard abstraction layers such as GSSAPI and SASL, it is easy to use Kerberos either directly or indirectly to secure many standard applications and protocols, including:

SSH (OpenSSH, ssh.com, VanDyke VShell/SecureCRT)
IMAP and SMTP (Cyrus, sendmail, postfix, Thunderbird, OS X Mail, Alpine)
Subversion
CIFS/SMB (Samba, Windows, Netapp)
Database (SQL Server, Postgres, jTDS, FreeTDS)
HTTP (Apache, nginx, all major web browsers, curl, client HTTP libraries
in Perl/Python/Java/C/...)
DNS (authentication for dynamic update, implemented by both Windows and BIND)
NFS

All these protocols and implementations have built-in Kerberos support ready to be used, if only you provide the infrastructure and know how to do it. This is not just theoretical; where I work, I am in charge of the Kerberos infrastructure for my firm, and we have all these applications and more. They all interoperate seamlessly across both Windows and Unix; our users log into their Windows or Unix desktop, type their password once, and then never type it again while accessing all these services, both directly and after using SSH to log into other hosts (where their Kerberos credentials are automatically forwarded and used). Credential delegation in different flavors is available to allow authorized servers to access further services on a user’s behalf via controlled use of the user’s identity. We do not have the nightmare of managing SSH hostkeys across various platforms and clients (OpenSSH known-hosts files, PuTTY registry keys, etc.); Kerberos authenticates our SSH servers as well as their clients.

If you have narrowly defined needs, then you can get away with other systems. If all you want is single-signon to web applications from full web browsers, for example, then you can use any one of several schemes — but if you also want to access that web app programmatically from a simple program that doesn’t have a Javascript engine and a user to type in a password, you’re pretty much stuck. With Kerberos, the same credentials work the same way in both scenarios.

None of this is to say that Kerberos doesn’t have its weaknesses, or things which should be improved. The use of Kerberos in HTTP (“HTTP Negotiate”) is a hack with problems; really, what we need is pervasive implementation of Kerberos ciphersuites in TLS. Using Kerberos to secure data traffic lacks forward secrecy, which is increasingly important these days; we need a GSSAPI mechanism which combines Kerberos authentication with a Diffie-Hellman exchange, as the SSH GSSAPI key exchanges do; once that exists, it can work transparently with any correctly written SASL client that uses a security layer (as do several of the cases mentioned above). This avoids the combination of Kerberos and TLS in separate layers, which has too many round trips and requires PKI when Kerberos by itself is sufficient.

Also, much of this usefulness is due to the wide adoption of GSSAPI and SASL in protocols through which Kerberos is used, rather than specific properties of Kerberos itself; other mechanisms made usable as GSSAPI mechanisms might enjoy similar usability, and there is current work on doing this for OAuth, for example. Kerberos has the advantage of still allowing for simple password-based authentication, while allowing for stronger methods as well (public-key certificates via PKINIT and OTP schemes are both supported), whereas PKI is tied to needing a second factor of some kind to hold the user’s private key and trusted CA certificates, which has limited its adoption for user authentication for quite some time.

In any event: if you want single-signon today, with existing systems out of the box, across a wide variety of applications and protocols particularly in an open-systems environment, Kerberos is pretty much the only game in town: nothing else matches its pervasive availability, usability and support in existing products and protocols, both commercial and open source.


The text that you quoted describes a session fixation problem. But the entire report (I included it below for reference) describes a problem with logout. Specifically, it says that logout only happens on the client side, not the server side. Per the OWASP Session Management Cheat Sheet's discussion of the logout button:

  the web application must invalidate the session at least on server side.

So, if correct, this is a vulnerability, just not session fixation. (I'm not sure if it has a name.)

The OWASP's guide for Testing for logout functionality describes how to test for this, but the report's instructions to reproduce, included below, also describe it.

Just to be extra sure, you may also wish to test for a session fixation vulnerability. Just follow a session fixation testing guide, such as this one from OWASP.

Vulnerability Report

bug-session fixation
Severity: Medium

Summary:

The application does not set a new Session ID in the cookie after what
appears to be an authentication attempt by the user. If this was a
successful login and the Session IDs are stored in cookies then this
application is affected by Session Fixation vulnerability.

To reproduce this vulnerability

1.open chrome and download edit this cookie ad-don
2.now open https://www.reddapi.com/ and log in
3.now go to edit this cookie addon and click export all cookies ...
  by clicking this we get the cookie copied in clipboard..
4.logout from your https://www.reddapi.com/ account...
5.if needed u can close and open your browser.
6.now again go to https://www.reddapi.com/ but don't login..just
  simply go to edit this cookie addon and click import a cookie
  and paste the code which we previously exported.
7.after pasting just refresh the page and that's done you are now
  logged into your account without login details...

problems faced

the problems face if the vulnerability exits are
1.anyone can easily hijack victims or users session and get into his account
2.cookie stealing is the best way the hacker can get into and account..
  it would not take more than 5min to steal someones cookie using php n all...
3.even friends can fool the victim and get him hacked..


Do I need logging enabled in my rules in IPFW for sshguard-ipfw to work/blacklist ip's?

Logging is open to choice and I will explain why. It is easier to block ALL (drop, not reject) and allow in ONLY trusted addresses. This allows you to make ONE rule versus N amount of rules you'd be generating by blacklisting. Have a look at the average blacklist and you will find that there can be well over the 1k mark on any given day. What occurs is the following:

Firewall (be if IPFW, IPTables, a Checkpoint FW, SSG, etc.):

Connection is coming in --> Check against the first rule
Connection is coming in --> Check against the second rule
Connection is coming in --> Check against the ... rule

Your machine will have to process N amount of rules - where N is the amount of IP addresses in your blacklist. Not to mention, I know of ssh-based bots which spoof addresses, so there is also the possibility of spoofing: the machine itself, the default route... 0.0.0.0/0 (everyone). Think about that for a moment. If I did the following:

nmap -sS YOUR.IP.ADDRESS -p 80 -D 0.0.0.0,YOURGATEWAYIP,YOURUPSTREAMGWIP

Your logs will show entries from 0.0.0.0, Your Gateway IP, Your Upstream GW IP, in turn creating a FW rule to block connections. To avoid this, you'd have to WHITELIST IP address, creating even more rules:

Connection is coming in --> Check against the first rule --> WHITELISTED

This packet will be sent immediately depending on the placement of the rule (it would have to be one of the first. Otherwise:

Connection is coming in --> Check against the first rule
Connection is coming in --> Check against the second rule
Connection is coming in --> Check against the ... rule
Connection is coming in --> Check against the first rule --> WHITELISTED

The bigger your rules become, the harder it is to maintain. If at all possible, its better to do the following:

firewall --> this Whitelisted address is allowed all others blocked

One rule to process versus cumbersome rules. Now, back to logging; what would be the goal of logging. Attacks come, attacks go. The Internet is like outerspace filled with junk. Many of the ssh attacks are coming from compromised hosts, not the actual attacker. Many are parts of botnets, some of which are 100's of thousands strong. Not only are you wasting processing power, eventually, you are also wasting space on the drives since logs can grow.


These are scans for proxy servers. The first one tests for a SOCKS4 proxy, the second one for a SOCKS5 proxy, and the third one tests if your server allows forwarding via a CONNECT request to "valuable" ports (SMTP in this case). You don't have to be worried about that, it's what you expect to see on public servers. Your server answers with return code of 400, so everything is fine.


Shellcode that is smaller than 295 bytes that spawns a shell

A null free 211 byte bind shellcode is available from  Dafydd Stuttard, NGS Software.

http://code.google.com/p/w32-bind-ngs-shellcode/

I tested it in my labs, and it works well.


Why do some sites prevent users from reusing their old passwords?

The first question is: why do some services require passwords to be periodically changed. The answer is "Risk Mitigation".

Corporate governance requires IT security policies to be defined in accordance to a risk management plan. One of the question that risk management plans ask is how can one mitigate a risk if it occurs. In the context of passwords, the question is how can we limit the damage of a password leak.

If the system administrator is aware of the leak then users can be notified and other steps can be taken. To reduce the damage cause by a password leak of which the administrator is not aware, the lifetime of passwords is limited so that any leaked password can be used only for a short period of time.

So services require periodic changing of passwords. The problem is that users really don't like changing their passwords. So what users used to do when forced to change their password was to change it twice - once to some temporary password and then a second time back to the original password. This of course nullifies the purpose of the policy to require passwords to be changed.

So the next thing administrators did was store the last two passwords and check that the new password is different than the previous two passwords. The wily users countered that by changing the password three times - two temporary passwords and back to the original password.

You might think that users wouldn't go to all that trouble just in order to not change passwords, but this is what actually happened. A administrator friend of mine once compared the hashed passwords in his system after a year and found that almost all passwords were the same - despite the fact that that password policy forced users to change passwords every three months.

So the administrators started storing the last 10 passwords. And the users countered by using a fixed password plus a single changing digit at the end for a cycle of 10 passwords. And thus we've reached the situation today where many systems store all previous passwords.

Having said all that, the real value of these policies is dubious. Human beings have a limited capacity for remembering passwords and if it's wasted on remembering these rapidly changing passwords it can't be used to keep different passwords on different sites (which is much more important).


HTTPoxy - What about HTTPS_PROXY when dealing with HTTPoxy vulnerability?

Even if the context is missing I think you are referring to the httpoxy vulnerability where it is possible for an remote attacker to set the HTTP_PROXY environment variable using a HTTP Proxy header. The base of this vulnerability is that in a CGI environment the HTTP_xxx environment variable is set if the HTTP header xxx exists. Since this only affects HTTP_* variables and not HTTPS_* variables it does not affect HTTPS_PROXY.

Apart from that both HTTP_PROXY and HTTPS_PROXY are only relevant for requests done by the CGI script and is not related to how your site gets accessed.


Who is responsible for generating public key during secure communication?

["Facebook" here is just "an example of someone that wants a certificate."  There is no inherent special Facebookness about this situation.]

  Who generated that public key that I can see in facebook certificate?
  Is it generated by Facebook or that intermediary CA?

Facebook generates the "keypair" consisting of a public key and a private key.
Facebook then generates a Certificate Signing Request (CSR) which includes the public key, and send the CSR along to the CA.
The CA signs the public key based on that request and returns the signed public key (the "certificate") to Facebook.
Facebook installs the private key and the certificate on their web server, and you see that signed certificate when you ask your browser to show you the security of the connection.

  Does the public key change often or it gets modified only when the
  certificate expires?

Ideally it changes whenever the certificate expires - one could submit a new CSR using the old keypair and get a new certificate for the old public key, but that would defeat the purpose of expiring certificates, which is to ensure key turnover.

You should also be aware that many modern ciphers used with TLS, like the ECDHE variants, validate the connection using the presented public key (certificate) as described, but then spin up a new ("ephemeral") keypair on the fly and use that to actually protect the encryption.  So the certificate you see in the web browser is not the actual certificate used to protect data, and the certificate used to protect data has an exceedingly short lifetime.


They are doing a man-in-the-middle attack which needs the user to either ignore security warnings or to explicit import the CA used by fiddler. For more discussion about this topic have a look at How can I prevent a man-in-the-middle (MITM) attack on my Android app API?


With javascript in the browser, how can I sign some data without directly manipulating a private key?

It's not possible, not without significant effort by browser authors (or browser plugin authors) to make it possible. Remember, the point of signing something is to verify that its authenticity - that is, that the signer meant to sign that thing, with that key, and they are the only one with the key - so having a way for web page content (which is inherently untrustworthy code, from a browser's point of view) to access a user's signing keys would be a major security risk! Even just enumerating installed keys would allow for user fingerprinting and tracking.

Now, a browser (or plugin) could attempt to do this securely, by offering a JS API that basically prompts the user "A script on site  is attempting to access your certificate store. [Allow] [Deny (default)]" and then a similar prompt (if the first is approved) for access to your private key (and password for it if needed). I would be very cautious about such a feature, though.


Difference between these two extracted public keys?

Because they're in different formats.
You can compare this to an image file, roughly. The same pixels, with the same values, can be stored in multiple different ways, depending on the image format. A 1x1 image made of 1 black pixel will look radically different in a hex editor, depending on whether you save it as PNG, JPEG or TIFF.
Likewise, OpenSSL and OpenSSH store public keys in two completely different formats, even if the underlying cryptographic primitives (the public exponent and the modulus) are the same.
PEM Format
OpenSSL uses the PEM format by default. This can be easily identified by -----BEGIN PUBLIC KEY-----. If you use the command openssl -in mykey.pub -pubin -text, you can see the following output:
RSA Public-Key: (2048 bit)
Modulus:
    00:c8:5e:9f:52:16:a0:77:ae:dc:20:14:25:95:9e:
    5c:0e:08:ff:1c:35:27:9c:dd:62:a3:58:1a:39:5b:
    65:67:19:2b:5d:05:d7:05:1d:dd:0a:43:eb:b8:35:
    f2:85:c9:1d:32:66:22:4a:08:ef:04:10:a7:f3:52:
    ef:62:4b:26:81:f4:ab:00:c3:7e:16:29:5e:14:7f:
    e5:f8:3f:2c:62:de:61:ba:6d:d4:4b:d2:13:3c:46:
    c4:22:6d:19:9a:6f:06:3f:96:1e:79:58:09:d1:f3:
    3c:e4:24:b3:6f:5a:fc:01:5e:ff:fb:25:fe:ea:30:
    45:87:57:2c:68:ac:3d:55:c7:bb:d6:23:0b:40:68:
    21:bb:97:1c:5e:66:08:49:eb:a0:a5:e4:24:8f:16:
    08:55:8e:0a:e5:72:59:4c:bf:a1:f1:94:ed:b3:84:
    66:94:32:87:c4:fc:d4:32:35:05:03:3a:b1:50:26:
    ce:41:21:7b:a1:e3:d5:5e:65:f3:1e:81:fd:65:db:
    1b:f9:21:cd:e4:b8:2c:5d:53:63:88:76:b4:c7:34:
    50:c1:89:2f:68:1b:5f:d2:9c:31:47:43:3c:30:3c:
    86:94:da:32:f6:0f:30:2c:f4:2a:64:8c:15:aa:0e:
    6d:f1:33:14:d5:b3:4c:95:08:81:cd:43:02:ac:fe:
    f4:21
Exponent: 65537 (0x10001)
-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyF6fUhagd67cIBQllZ5c
Dgj/HDUnnN1io1gaOVtlZxkrXQXXBR3dCkPruDXyhckdMmYiSgjvBBCn81LvYksm
gfSrAMN+FileFH/l+D8sYt5hum3US9ITPEbEIm0Zmm8GP5YeeVgJ0fM85CSzb1r8
AV7/+yX+6jBFh1csaKw9Vce71iMLQGghu5ccXmYISeugpeQkjxYIVY4K5XJZTL+h
8ZTts4RmlDKHxPzUMjUFAzqxUCbOQSF7oePVXmXzHoH9Zdsb+SHN5LgsXVNjiHa0
xzRQwYkvaBtf0pwxR0M8MDyGlNoy9g8wLPQqZIwVqg5t8TMU1bNMlQiBzUMCrP70
IQIDAQAB
-----END PUBLIC KEY-----

That's all the information contained in the public key. The PEM format is simply base64-encoded DER format.
DER Format
A standardized format for storing cryptographic material, which uses the ASN.1 notation. OpenSSL also supports it, and DER files are smaller than PEM files. The disadvantage is, since they're binary, you can't easily copy and paste them as text, which is why PEM is generally preferred.
SSH Format
OpenSSH uses the "SSH Format" by default, which is described in RFC 4253, section 6.6. It's a rather simple format, and it works. Since the underlying cryptographic primitives are the same, you can easily convert a key from one format to another.


Feasibility

It's not impossible, just terribly impractical. The issue of remote electronic voting is not so much a lack of cryptographic primitives than a lack of trust. You as a voter must trust your computer and the platform on which you vote to correctly register your vote. You must still trust your own computer to correctly verify the vote you cast. The organiser must also trust you and all the other voters that your computers are under your control, and that it is you indeed who are casting your own vote.

The state of the art is a paper published last year in Computer Security Foundations by Mark Ryan and his team. It shows that it is at least possible to cast votes without trusting your computer, if you choose to trust a small piece of hardware instead. It's still very inconvenient, but this solution is already more practical because the trusted hardware is more readily manufactured, verified and distributed than a full-blown computer.

Anonymity

You need to guarantee anonymity mainly so the organisers cannot infer who you voted for. If the organisers are able to query the voting system at any point in time, they could infer all individual voter choices by querying the system before and after any vote is cast.

Note that there are different legal, technical and societal concerns about e-voting and remote voting in each country. Wolter Pieters did his PhD thesis on the controversies surrounding electronic voting, and compared the issues between the USA, the UK, the Netherlands and Estonia. It's a very good non-technical introduction to the challenges of voting and electronic voting.


Sniffing WPA2 PSK traffic with the key but without association

No

Any user who has the psk has the ability to decrypt all traffic encrypted with that AP using WPA2-PSK. The cipher keys are generated from that PSK all the attacker has to know is the psk and what functions the AP and Client use to generate the cipher keys, which he/she already has from previously associating themselves with access point. If the traffic has other layers, ssl  for instance, well then that part of the traffic is "safe". However the Broadcast key (BES) might and should be changed by the AP
whenever a client associates and also when they leave the LAN.

Some of those attacks you posted are for attackers who don't have the PSK, i.e. it  changed or they never used that AP, can capture the 4-way  PSK handshake which usually contains a MAC, or password-key based hash of some used-once string (nonce). The attacker can then brute-force that hash key to obtain the PSK. The key used to create the MAC is the PSK which is the password or some pseudo-derived version of it. "Deauth" Allows an attacker to kick someone off the network to force the handshake to happen again so they can capture it. Basically faking packets that tell the client to disconnect.


I am the Security Specialist at a SaaS company and we were looking at the exact same issue earlier last year.

The main issue you will run into is cost.  If you want your database to be readily available, but encrypted 'at rest' you basically need a beast of a server that does nothing but handle the encryption/decryption process.  As decrypting the data that you need to read is going to give you a performance issue, even with a beast of a box, you are still going to get at least 1 or 2 milliseconds delay added to your queries.

We looked into SafeNet's ProtectDB, but as we are not currently going for a PCI or a HIPPA compliance, we deemed that the ~$50k+ investment cost was not worth the limited benefit.

EDIT: ProtectDB is basically a separate server that houses all the encryption keys, and does a scan of your database to see where the data is.  When you are making a Database query, the ProtectDB box receives the traffic instead, and makes an encrypted connection to the database, decrypts the column / table, and returns the data.  Thus making it so that your devs/users are not actually directly connecting to the database anymore, instead you are connecting to the ProtectDB box.

Really, you are only getting two benefits: preventing someone from walking into your data center / DR site and stealing the physical box, and that is what security guards and physical locks are there to prevent. Or, if you get a major external network breach, and someone manages to get your database.  In both cases, you are really only adding time to how long it will take to break anyway.

I would honestly recommend that you invest that money into a WAF (if you don't already have one), like Incapsula, instead.


Which layer of OSI model does end-to-end encryption and decryption happen in a network? Why?

Encryption can happen at any of the levels of the OSI model.  TLS happens at something like the session or transport level.  Quantum Crytography isn't exactly encryption, but would be at the physical level.  PGP in an email would be at the application level.

Remember that the OSI model is just one model, and largely represents an idea of separation of concerns and layering.  TCP/IP doesn't map entirely to the OSI model, and encryption doesn't really fit within the model at all.

Speaking from a "separation of concerns" perspective, where you put encryption depends entirely on what you're trying to do.  If you had to put encryption in a "place", you might say that it lives outside of the OSI model.


How secure is a Windows PC that is routed through a Linux PC?

In the scenario you describe, your Linux box is essentially acting as a network firewall for your Windows machine. So your question basically boils down to "Do I need a host-based firewall if I am already using a network firewall?"

The answer to that question is no, you don't need one. However, it would be helpful to use one. See the concept of Defense in depth.

A good explanation on what host-based firewalls can do compared to network firewalls can be found in this question.


Obsolete cryptography (SHA1) warning although certificate uses SHA256

The error message is just misleading

You said yourself:

  I know that AES_256_CBC isn't considered modern cryptography, so the warning about obsolete cryptography would still appear.

And that is why you get that message.

Now unfortunately the message itself is not very clearly phrased.

SHA-1 is used in several circumstances. And here the "SHA-1" refers to HMAC message authentication and not to its use inside certificates.

From the Chromium TLS page (Archived here.):

  Message Authentication

  You may see:

  “The connection is using [cipher] with SHA1 for message authentication.”

  This actually means that the connection is using HMAC-SHA1 for data integrity, rather than as a certificate signing algorithm (e.g. sha1WithRSAEncryption). The HMAC construction is strong enough that it is not broken when used with SHA1 (or even MD5) as the hash function, so this is not currently deprecated.

What to do
Enable and have the server prefer a cipher suite that Chrome likes better. Namely: Something with forward secrecy and either AES-GCM or CHACHA20_POLY1305. (The TLS page recommends TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256.)

Since that is already in your list, all you have to do is change the server's preference for it.


The reason other devices can see each other on the campus network is because all the clients are on the same "subnet" or area of the network, in which case there is no filtering.

NetBIOS, Bonjour and other discovery services use the "broadcast" ip of the network to advertise the machine's presence.   So, let's say the campus network internal range is 10.0.0.0-10.0.255.255.  They would send packets to 10.0.255.255, to advertise the presence of the device to the rest of the network.  Essentially, they keep sending a message that says "I'm Here! I'm this device!" to everyone on the LAN.

Restrictions for broadcast-based services like NetBIOS and Bonjour can be put in place at the switch level, provided layer-3 capable "managed switches" are used.   There are many ways to handle this, IT can make it so each device can only communicate with itself, or to a subset of the network (e.g. an individual VLAN).  The broadcast for the domain can also be disabled entirely, but either approach might cause issues for users trying to get things to work like chromecast etc.

Often this requires fine-tuned rules.  For example, the MAC address of the Apple TV can be set to a static IP reservation.  Then, this static IP can be allowed to receive traffic from certain other devices, but not others -- so only authorized IPs may send video traffic.  As you can see however, this is cumbersome to maintain and many network administrators just leave the network open internally.

As a side note, out of the box many WiFi access points support restriction of clients so they cannot communicate with other machines also connected to the network, only the internet.


Must the distinguished subject name of an issued SSL Certificate match that of the generated Certificate Signing Request?

It is legal and possible for the CA to take a CSR and modify the DN it finds there before issuing the certificate.

For instance, with StartSSL free certificates they ignore the DN provided and issue based solely on the public key, the domain name requested (CN), the country (C), and email of the requester (E).  And according to the user interface, everything but the public key comes from the interactive request process, not the CSR itself:


How does WannaCrypt detect when someone pays the ransom?

Until now, it will be manually operated. But now there is a new path for the money - you got a text message with a request to contact the operator with the private bitcoin wallet address:


As you stated, the -Pn flag assumes the host is already 'up' and sends no packets to confirm, while the -sn flag disables port scans entirely.

In summary, what you are doing with a scan like this is attempting a reverse DNS resolution of the host, which attempts to enumerate the name of the host (in this case taking the IP and searching to see if it resolves to a domain name), as it already assumes the host is 'up' and is further instructed to not perform any port scanning.

The reverse DNS resolution is generally attempted to be determined with the help of your resolv.conf file (Unix) or the Registry (Win32).

Further information about this type of scan can be gleaned by either running Wireshark or tcpdump and monitoring the traffic generated from the scan, as well as by passing the -v and --reason flags. Both of these flags will provide additional verbosity and aim to provide more clarity about the output.

The below links are great resources for understanding the anatomy of an Nmap scan.

Sources:

https://nmap.org/book/nmap-phases.html
https://nmap.org/book/man-host-discovery.html


Kaminsky attack is a technique with which you can flood the DNS recursive server (like your gateway) with DNS replies that ultimately match the response that the recursive server is originally looking for. This is also called DNS cache poisoning.

An alternate technique would be to ARP-spoof your IP as the gateway and let everyone make the DNS query to a DNS server running on your machine. Your rogue DNS server can then reply with the forged DNS records.


Is detecting if an email has an account considered a vulnerability with AWS cognito?

Yes this is a vulnerability, more than one vector is depend on same logic, examples listed below.

SMTP VRFY option enabled
OpenSSH Username Enumeration
SIP INVITE/REGISTER Response User Enumeration

BUT as you mentioned vulnerability is never black and white, AWS can consider this is a risk and they may implemented rate limiting, if so they are reduce risk significantly.


Given a large enough sampling of public keys could one begin to identify a private key?

No.

Examining public keys gives you no insight, no matter how many you see, that would allow you to derive the private from the public key.


A VPN allows two different entities separated by out of control network elements to be seen as members on a single controlled network (definition of Virtual Private Network). So:

if all your servers are on same LAN inside your own building, then you do not need a VPN between them
if employees only use ssh to connect to a server, then you do not need a VPN for that access (ssh already offers an end to end security)
if you have different servers in a datacenter, and you have no control whether other servers share the same network, then a VPN to isolate you servers exchanges would make sense.
if you need to use various protocols between your employees's computers and your servers, and the exchanges and not limited to your LAN, then again a VPN would make sense


This is actually coming from where CakePHP is renewing its session. Culprit can be found at:

CakePHP 2.4: https://github.com/cakephp/cakephp/blob/2.4/lib/Cake/Model/Datasource/CakeSession.php#L686

CakePHP 2.6: https://github.com/cakephp/cakephp/blob/2.6/lib/Cake/Model/Datasource/CakeSession.php#L721

And the documentation in setcookie has clearly said that:

  Cookies must be deleted with the same parameters as they were set with. If the value argument is an empty string, or FALSE, and all other arguments match a previous call to setcookie, then the cookie with the specified name will be deleted from the remote client. This is internally achieved by setting value to 'deleted' and expiration time to one year in past.

This is why you get a non-httponly setcookie call from whenever your session is renewing, especially you are doing a logout action.


What are a keypair and a public key ring?

Does a keypair mean a pair of private key and public key?

Yes.

  The book also says there is a public key ring. Does it mean the place
  which stores the public keys created locally and received from others?

Yes.

  Is there a private key ring?

In a default setup you would only have your own private key. Therefore it would not make a whole lot of sense to have a keyring containing only a single key.
This term is therefore not really common.


Can the Truecrypt downloads from the Gibson Research Corporation website be trusted?

Even if we assume the files on GRC are untainted, I would still recommend avoiding it because Truecrypt is no longer under development.  I would recommend using VeraCrypt instead. For the following reasons:

VeraCrypt is an actively developed fork of Truecrypt
VeraCrypt can manage volumes created using Truecrypt
There was recently an audit performed on VeraCrypt.  26 vulnerabilities were found; 8 of which are critical, which may reflect vulnerabilities in Trucerypt code.  The VeraCrypt developers have patched many of the vulnerabilities already.
More details are available here:
https://ostif.org/the-veracrypt-audit-results/


The scheme you are describing is called "Hybrid Encryption for Multiple Recipients" and is already well-implemented in GnuPG.

The user David Segonds described it well in this answer on StackOverflow:

  GnuPG does multi-key encryption in standard.

  The following command will encrypt doc.txt using the public key for Alice and the public key for Bob. Alice can decrypt using her private key. Bob can also decrypt using his private key.

gpg --encrypt --recipient alice@example.com \
    --recipient bob@example.com doc.txt

  This feature is detailed in the user guide section entitled "Encrypting and decrypting documents"

The scheme works just as you described it. First, a random Data Encryption Key (DEK) to be used with a symmetric cipher is chosen. Then this key is encrypted, one copy for every recipient, with their respective public key.

Finally, the actual data is encrypted with the DEK. Then the encrypted keys and the encrypted data are stored as a file to be sent to the recipients. For example, the file could look like this:

                  +--- Encrypted DEK
                  |    with the public  +--- This file has been encrypted
                  |    key of Bob       |    by the Data Encryption Key (DEK)
                  v                     v
+---------------+---------------+-----+----------------+----------------------+
| Encrypted DEK | Encrypted DEK | ... | Encrypted File | Signature of Creator |
+---------------+---------------+-----+----------------+----------------------+
  ^                               ^                           ^
  |                               |                           |   (Optional) Signature
  |    Encrypted DEK with the     |    More encrypted DEKs    +--- of the creator
  +--- public key of Alice        +--- of further recipients

Of course, this graphic is purely demonstrative and not actually how the file is structured.

In order for Bob to decrypt the data, he would first validate the signature of the file, if it was signed. Then, he would check all the encrypted DEKs, until he finds the one he can decrypt with his private key.

Once Bob is in possession of the DEK, he can use whatever symmetric cipher was chosen to decrypt the file and receive the plaintext.


Does encrypting data multiples times over make it any more difficult to break into?

The problem with simply dogpiling one encryption algorithm on top of another and believing that everything will somehow be "more secure" is that if you haven't studied the algorithms in detail, you won't have a full understanding of their weaknesses, or enough understanding of the side effects of this operation.  That's not intended as an insult, I'm simply inferring from the question that you're not a cryptanalyst, and you haven't done these studies.

Have a look at Triple DES.  It was designed as a replacement for DES once it was recognized that DES was too weak to withstand ever-improving brute force attacks.  DES has 8 byte keys, so logically since DES should withstand a brute force attack of 2^64, Double DES should withstand an attack of 2^128.  So why use Triple DES and not just use Double DES?  It turns out the estimate of strength is not even close to correct.

First, DES discards the top bit of each key byte, so DES has a key size of only 56 bits -- 55 bits once you factor out XOR reflection.  An attacker can store the output of a brute force attack on the first instance of DES, then attack the second instance matching any of the stored outputs, creating a meet-in-the-middle attack.  This results in an attack of 2^55 + 2^55, which is 2^56.  All that work to run DES twice yields a one bit of improvement in strength.

So Triple DES obviously doesn't withstand an attack of 2^192.  3DES does improve this to 2^111 bits of strength, which is still plenty strong, but it's a far distance from the implied strength of 2^192.

It is not obvious that encrypting the output of one pass through DES with another pass is easily broken, yet cryptographers figured that out.  Can you offer strong evidence that your two-layer encryption isn't similarly flawed?

Crypto is hard because the random-looking bytes coming out of an encryption algorithm look very much like they've been successfully scrambled.  But there isn't an attribute you can test for to know if the encryption is effective or if it's breakable.

So the advice generally given is "do not invent your own crypto algorithms".  Going along with that, it is not recommended to invent your own protocols, either; if you must, you have a lot of work to do to prove they're secure.


The oldy but goldy one is John the Ripper which is open source and can be extended to your "program.exe". Needless to say, you need to know how the executable was encrypted. You cannot use John, or even your own extended version, to decrypt container formats for which the format and choice of algorithms isn't known.

Kerckhoff's principle states that the security of a crypto-system should not depend on static information such as the algorithm. Unfortunately that does not mean that it is necessarily easy to decrypt if the protocol or algorithm is not known or kept secret.

You may be able to identify the format of the file by using the Unix file command, other tools or even a text or hex editor. Looking at the header of the file does indeed make most sense initially, as safesploit muses.


Can I get a public key from an RSA private key?

can I get a public key?

It's easy using openssl rsa:

$ openssl rsa -in the-private-key-from-your-question.pem  -pubout
writing RSA key
-----BEGIN PUBLIC KEY-----
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCtrKVnwse4anfX+JzM7imShXZU
C+QBXQ11A5bOWwHFkXc4nTfEOr3fJjnRSU5A3IROFU/pVVNiXJNkl7qQZK5mYb8j
3NgqX8zZJG7IwLJ/Pm2sRW5Qj32C/uJum64Q/iEIsCg/mJjDLh1lylEMEuzKgTdW
toeLfxDBL2AJ20qXzQIDAQAB
-----END PUBLIC KEY---

If you want to get an idea of what is contained in a key file, you can pass the -text option to see a human-readable (sort of) debug dump. This way you can see that a key file contains both private information but also the public information. Especially it contains the modulus and publicExponent which fully describe the public key:

$ openssl rsa -text -in the-private-key-from-your-question.pem
Private-Key: (1024 bit)
modulus:
    00:ad:ac:a5:67:c2:c7:b8:6a:77:d7:f8:9c:cc:ee:
    29:92:85:76:54:0b:e4:01:5d:0d:75:03:96:ce:5b:
    01:c5:91:77:38:9d:37:c4:3a:bd:df:26:39:d1:49:
    4e:40:dc:84:4e:15:4f:e9:55:53:62:5c:93:64:97:
    ba:90:64:ae:66:61:bf:23:dc:d8:2a:5f:cc:d9:24:
    6e:c8:c0:b2:7f:3e:6d:ac:45:6e:50:8f:7d:82:fe:
    e2:6e:9b:ae:10:fe:21:08:b0:28:3f:98:98:c3:2e:
    1d:65:ca:51:0c:12:ec:ca:81:37:56:b6:87:8b:7f:
    10:c1:2f:60:09:db:4a:97:cd
publicExponent: 65537 (0x10001)
privateExponent:
(…)


Internal IP addresses allowed access to all DMZ hosts

The same vulnerabilities that exist between two internal workstations on the same network.

Things such as:

NetBIOS access
Accessing admin shares (C$) or any shares for that matter
Brute forcing DMZ accounts over the network
Remote registry access
RDP access

That's just for starters.

It's bad practice to allow unrestricted access from internal resources to DMZ assets. Why you ask? Insider threats - which could essentially be broken down into 3 categories:

Employees with deliberate malicious intent
Incompetent employees who may accidentally cause an outage
Internal machines that have been compromised and are part of a BOTnet / controlled by a remote attacker.


Is it safe to upload a read-only encrypted volume to a cloud folder?

If it is never modified, and is always at rest, then the confidentiality of the contents will be as strong as the encryption key. In other words, an attacker would need to know the encryption key (or the password it is derived from) in order to decrypt the contents. However, know that VeraCrypt uses XTS mode, which is not authenticated. An unauthenticated mode means that it may be possible for an attacker to make predictable modifications to the plaintext just by modifying the ciphertext, without even knowing the key. For XTS, an attacker can randomize any 16 byte sector. If integrity is not part of your threat model (for example, if you digitally sign the volume), then this is not an issue.


Is the fact that Tor's development is largely government funded cause for concern?

Since the source code is open, it can be vetted.  The bigger problem is that a large number of compromised nodes makes it easier to try to track, but this has nothing directly to do with the development itself.  As for why the government would fund something like this.  While it does make it easier for bad people to do bad things, it also makes it easier for good people to do good things in bad countries and that's still something the US government generally likes to see happen.  The technology enables a much higher level of freedom in countries that otherwise would restrict freedom.  While it can make it harder to stop bad people, it still has enough benefit for good that it is worth the risk of bad people abusing it.

That all said, can we be sure that they don't have some way to get around it.  No, but based on the amount of research the government has been known to do on how to try to break Tor, it does seem unlikely they have some magic switch.


There was WeaponX in 2004, there is even a guide here on how to develop one yourself. Since OSX is a combination of Mach and BSD, there have been rootkits specially developed to target the Mach or Unix side or both.

I use Rkhunter on my Unix machines, there is a version for OSX as well, so I suggest you take a look at that.

The problem with a rootkit is there are many places it can go hide itself, plus they are often made to be very hard to detect.  They can provide false process information.

I've never written one myself, but rkhunter is open-source so I suggest you start there.

Also if I'm not mistaking(but not sure), it makes MD5 hashes of your binaries and kernel modules and then checks this every so often. It notifies you what has changed. Might be that you did an update. If not then you might want to go look why that binary got changed.


SSL certificate trust chain shows root certificate with 1024-bit public key - Is this evidence of a MITM attack?

Both chains are actually OK. The third certificate in both cases matches a real root CA (I checked against my machine's root, which fingerprints I then checked against the CA's sites via HTTPS on a separate iPad which is newly-purchased and should have proper certificates installed).

Here's what's happening: Certificates and public keys don't have a one-to-one relationship. A certificate binds a public key to an entity (the subject of the certificate); an entity might obtain several certificates for the same key, in case there's an issue with one of the certificates later (specifically, an issue not affecting the key).

That's what's going on here. Both chains have, as their third cert, a certificate with the same key (and subject) as the root ones on my machine (which are effectively known-good). But unlike the root CAs on my machine, they are signed by other (older, obviously) CA certificates; this is called cross-signing. This adds more options to trust the CA's cert; if you don't have it set up as a root, you can instead trust it because it's verified by a cert you do trust as a root.

In VeriSign's case, what's happening is they got a new root in the mid 2000s. They wanted to transition to the new root, but not all clients would have the new root installed. So, servers were given both the new root as self-signed (for new clients), and a chain from the new root to the old root (for old clients). In DigiCert's case, they have cross-signed certs with CyberTrust (which, incidentally, they recently bought) to give more options (I think the CyberTrust roots are older).

Because the chain has, somewhere along the line, a CA certificate with the same key and subject as a standard still-valid root CA cert, you don't actually have to worry about the rest of the chain after that point: even if a cert further down the chain is attacker-controlled, they can't be exploiting it at the moment.


To disconnect or not disconnect an intruder?

Knowing of an attacker and not disconnecting them will allow you gather evidence on the attacker such as determining the motive for the attack, determining the tools the attacker is using, determining the mode of operation of the attacker and maybe... just maybe, but not likely, being able to trace the connection back to the attacker. You could then try to use attribution to determine likely suspects.

Doing this could have legal and reputation implications. Imagine what Fox news will say on the air when they found out you allowed the attacker to have access to your network, compromising the confidentiality of company data. In my opinion, unless the attacker is currently in a honeypot that you all have deliberately setup, it's best to just disconnect them and look at the evidence you currently have.


Reusing HMAC state for multiple messages

It really depends on what security feature you want to achieve. Each pair "m,HMAC(k, m)" provides integrity in the following sense: the adversary will not be able to forge a pair declared valid by the receiver, that the sender did not compute in the first place.

You may want additional properties, though. For instance, you have a sequence of messages, and you want to prevent the adversary from altering it, i.e. dropping messages altogether, or inserting duplicates of old ones, or reordering them. This is a valid concern, and it is usually addressed with a sequence number. That is, each message is sent as "m,HMAC(k, s || m)" where s is a fixed-sized sequence number (e.g. encoded over 64 bits), starting at 0 for the first message, and then incremented at each message (with a 64-bit sequence number, you have quite some room -- it won't cycle back to 0 until "a long time"). That's how it is done in SSL, for instance (each SSL "record" has its own MAC and the MAC computation includes the sequence number). Note that the sequence number is implicit: it is used in the MAC computation, but needs not be transmitted over the wire, so it does not increase the size of what has to be transmitted.

Other constructions are possible, such as using the previous HMAC value (you send "m,HMAC(k, z || m)" where z is the HMAC output sent with the previous message). Your proposal also works, but only because the MAC is really HMAC, which is robust and which allows to grab its internal state relatively easily (although some implementations might not make it easy). Indeed, many MAC algorithms require a non-repeating IV and would not achieve proper security with your method. This is why I recommend that you use sequence numbers, since this is a standard, well-studied method which has the added benefit of being more easily applied to other MAC algorithms (and algorithm agility is a nice feature to have).

(The ability of HMAC to operate in an IV-less fashion is the feature which makes it the best generic MAC algorithm. If you have an IV nonetheless, because your messages are not only MACed but also encrypted, then authenticated encryption algorithms are preferred.)


The card needs to be referenced from the secret keyring.  The card is not a substitute for your keyring just a safer (in theory) place to keep the secret keys.

When you initially told gnupg to generate a (sub)key on the card or move an existing key to the card it will have manipulated your secret keyring on disk to contain a stub pointing to the card and slot where the key is stored.  You need your secret keyring from wherever you were when you initially set up the key on the card.  This should enable gnupg to find the key in its current location.

If you only have subkeys on the card and not the primary key then the primary key will still be in this secret keyring which would mean that anyone with access to it who can guess the password could generate new subkeys which defeats the purpose of the card.  If this is the case then keep the copy of the key with the real secret key somewhere safe.   To make a safe version of your secret keyring (where the primary key is inaccesible) you can use gpg2 --export-secret-subkeys then import the file wherever you need access to the secret subkeys (including the ones on the card).


IKE/IPsec connection attempt -Is this legal?

You need to read up on the state laws that govern computer activity.

By the sounds of things they were attempting to gain access to your network without permission. I'm not a legal expert but it sounds to me that it's not legal.

One could argue that what they are doing is legal because they did not actually gain access unauthorized access to your network. However it's my opinion that they shouldn't be trying, successful or otherwise.

Maybe you should try and get more information on what exactly it was that they were 'testing'?


Is there a process to identify threats related to a deployments?

Typically what you would do here is integrate some form of testing procedure into your deployment or post-deployment process.

This could be as lightweight as a simple port scan, which could identify ports left open inadvertently, or as large as a full 3rd party security assessment (aka penetration test) where you contract a 3rd party to review the security of the deployed system.


Replacement for One Time Passwords (OTP)

One-Time Passwords (not to be confused with "One-Time Pad", a theoretically perfect but practically heavyweight technique for encryption) are a sound concept which cannot, as itself, deprecate. It just means: a given password (i.e. a secret value shared between prover and verifier, used for authentication) can be used just once with the verifier; in other words, if the verifier (e.g. a server you want to log on) accepts a password but will reject any further attempt with the same password, then it is a one-time password.

One-Time Password schemes are systems which use the One-Time Password concept and establish rules and mechanisms for the two parties (prover and verifier) to actually share one-time passwords. Any given scheme can be weak or strong, broken, deprecated... but the concept is unharmed.

RSA SecurID tokens can be viewed as an incarnation of the concept of one-time passwords -- a variant with a clock, actually -- and they are very much alive.

HOTP is a free and open standard for generation of one-time passwords (with an internal counter), which can be implemented by extremely cheap hardware tokens.

(Traditional one-time password authentication schemes for Unix servers use software generation of lists of passwords, which users are supposed to print and keep in their wallet, striking out used passwords. This never got popular -- I guess it is too low-tech; users are not amazed enough to forget the inconvenience of fiddling with a tangible object).


Simple answer: if your employer has installed monitoring software on a computer, it's reasonable to assume anything you do on that computer could be monitored and recorded.


Should I tunnel multiple TCP connections through a TLS/SSL tunnel or use TLS/SSL for each connection?

This sounds like you are looking for a VPN but want TLS to provide the security (instead of e.g. IPSec). If platform compatibility is not your concern, then Microsoft has developed a Secure Socket Tunneling Protocol which uses such an SSL-VPN scheme.
If the "some kind of devices" you are talking about are also Windows-based, then you might not even need additional software to implement SSTP.

I do not have any more knowledge about SSTP, but the Wikipedia link and the MSDN resources linked in said Wikipedia article should provide all needed information.

An alternative would be OpenVPN which can also use TLS as underlying connection protocol, supporting server side and client side certificates for authentication.


Integrate PHP and WebSocket authentication securely

[...] if you can like or comment, and what it does when you try to do that, and in my opinion that logic should be done on the web server, on the PHP project.

Oh absolutely. Otherwise you would implement the checks on client side, in which case the web application decides, whether the user is allowed to comment/like a given post. You can do that but implementent server-side checks too! Otherwise nothing prevents me from pretending to be another user and sending the request directly without using your web app. Client-side checks should never be used as the only safety measure.

I'd also implement some sort of one-connection-per-user policy. In case somebody steals/guesses the users session ID, he/she can establish a websocket connection and maybe even use your other endpoints (depending on how they are authenticated). This is a weak spot, as your websocket connection can be established (and other endpoint can be used) by just throwing a valid session ID at your server (regardless of username/password in your scenario!). Make sure sessions time out after X minutes and session IDs are way harder to guess than password (i.e. using a cryptographic hash function or a safe random number generator).

Allowing only one Websocket for each session ID (and only one active session per user?) prevents an attacker from hijacking an actively used session unnoticed.

As usual "don't roll your own crypto" (if you think about using it as production software). As you already mentioned that "PHP gets the user data from the session ID", I assume you're using some sort of framework, as PHP does not do this on its own. Maybe the authentication functionallity is already implemented.

tl;dr

Implement all security checks at least on server-side (client-side is User Experience, not security)
Make sure that guessing session IDs in not feasible. This includes cleaning up sessions which are no longer in use. Maybe a policy enforcing one session per user and one websocket connection per session if it fits your use case. So nobody can hijack a session unnoticed.


Client Hello and Server Hello extensions indexes

IANA has the official extension registry and links to the defining RFCs:

http://www.iana.org/assignments/tls-extensiontype-values


What security implications does DNS prefetching have?

This could give rise to an information leakage vulnerability.

Say your whole site is served over HTTPS, without DNS prefetching disabled. There may be certain pages on your site that reference other external resources.

For example, imagine a banking website that customers can login to, and that the page for managing mortgages has some external links unique to that page.

With DNS prefetching enabled, a suitably places eavesdropper can infer that a user has a mortgage with that particular bank because when this page is visited DNS requests will be observed to resolve the external resource hosts referenced by that page.

Of course, if the user decides to visit those links manually, the same could be inferred without prefetching in this case. However, with more complex sites there may be unique combinations of resources on different pages giving away to observers which pages on the otherwise private session have been visited.

Whether this is an actual security vulnerability or not depends very much on the context of the website and the placement of links. Another mitigation instead of disabling would be to include all, or a random selection of, external references on every page using the

<link rel="dns-prefetch" href="//example.com" />

directive.


MySQL vulnerability bind address 127.0.0.1

Am I safe from mysql access from another host EVEN if they know my mysql credentials and port?

I wouldn't say "Yes". It, however, doesn't allow remote connections.

It's very likely that you'll have some sort of application hosted on the same server. So, if you leave anything like phpMyAdmin or Adminer, an attacker can easily get in using your credentials.


Is "BEGIN PGP SIGNED MESSAGE" optional to include in an armored message?

You refer to the marker of a cleartext signed message. If you use cleartext signatures instead of MIME then this marker is needed for the software to find out where the signed message starts. But again, this is only needed if you use cleartext signing.

For more information see Signature Handling in Emails which describes both ways of signing in more detail. GPG Signing: Traditional vs. PGP/Mime contains useful information too including information support for the various kinds of signing in mail clients.