How to protect against "padding oracle attacks."

The padding oracle is a mixture of a protocol flaw and an implementation flaw. Namely, a "padding oracle" leaks some information about secret data through how it reacts to maliciously crafted invalid input. A good protocol will first validate the input data through a MAC before considering decryption and its corollary, padding processing. That's what the "encrypt-then-MAC" construction is about. A bad protocol will do things in the wrong order, and may suffer from leakage by applying decryption first; that's what happens in SSL with CBC encryption modes.

If the protocol is bad, then the implementation must be specially shielded against the kind of invalid messages that attackers will try to handcraft in order to turn some implementation (e.g. a server) into a padding oracle. Such shielding is hard (e.g. the Lucky Thirteen attack demonstrates, in lab conditions, the theoretical possibility of leakage even with thoroughly shielded implementations).

The PHP function you link too is only about encryption; by definition, it cannot do anything against padding oracles. Protection against padding oracles is more at the protocol level. As is typical with PHP, dangerous functionality is provided with little warning, and a suboptimal API.

Designing your own secure protocol is even harder than shielding against side-channel attacks, so don't do that. And even if you do, don't do that in PHP.


Would the target URL be aware that multiple SSL Interceptions have happened?

In theory the target URL is not aware of SSL interception at all, no matter how many SSL interceptions you do. It only sees that it is doing the SSL handshake with some kind of client and can not see if it is doing the handshake directly with the browser or with some SSL interception device.

In practice it might be possible to detect an SSL interception device by the use of different ciphers or different cipher order or different protocol versions compared to the browser. Or it might be possible to detect interception by some other non-browser features, like accepting certificates the browser would not. But in this case only the device nearest to the server can be detected this way and further devices not, because they don't do SSL handshakes with the server directly.


How webmail's authorisation should work?

To ensure only the user has the key for his IMAP-Account, you can save the login credentials in your session symmetrically encrypted by a key, that is stored in a cookie. So the user can unlock the login credentials with his cookie, without that the webserver can't login.

Of course you have to ensure that all occurrences of the credentials are overwritten if not used anymore and are not readable by other processes.

If you have an attacker on the webserver, he will maybe able to read the session details, the encrypted credentials. If he is also able to get the cookie by eavesdropping the connection you have a problem anyway.


Is it bad practice to accept phone number or email as username?

Not on security side, but people are less likely to be willing to provide their phone number or they will just enter a fake one. So I suggest you to use phone number only if your application really needs that info.

I wouldn't care about people reusing their passwords, it's not your problem. This only weakens your security if the email service is compromised and the password is leaked. In almost every case users will use giants like gmail, which use various extra security measures to prevent hackers getting access to the account password. Just a simple and strong hashing algorithm would be enough on their side.

It is the same thing on your side. If you care about your users, you store their passwords hashed, as you probably already do. If you become the victim of a breach, and somehow the attacker gets to know the raw passwords of your users, it's absolutely their responsibility and stupidity if the attacker gets into their email account with the same credentials. But let that not be the case, store everything safely :)


How to prevent proxy server from HTTPS packet inspection?

The only thing I can think of is to create an SSH tunnel through the proxy server. Some proxies might allow this, others don't. So this is not a solution for all type of proxy servers.

For example:

Configure the SSH daemon to run on TCP port 443 and perform a reload the service.
Configure Putty to use a session to your home machine or VPS. Make sure to use 443 as the port.

Configure Putty to connect using the proxy server, it is required to know these settings.

Now configure a Tunnel, this is required to route all your internet traffic through the tunnel. Let's use port 8080 to bind to your local machine. Make sure the radio buttons look like the image below and click "Add".

Now configure your browser to use the local proxy server that is listening on TCP/8080. All HTTP traffic will now be forwarded through the tunnel, bypassing the inspection. However, they might see that SSH traffic is being transmitted.

NOTE:
In cases where group policies are enforced and the proxy server settings cannot be modified, it is recommended to download (or bring a USB stick) a portable version of Firefox.


Can root user have access to MySQL data?

The root user will have access to, at the very least, the database file that is stored on the computer. This means reguardless of how the service is configured they can copy and delete the data. If your databse is not encrypted by some means he will be able to modify the data too.


End-2-End and server to server encryption over home network

You could setup a Kerberos server on one of your Raspberry Pis. It would achieve secure authentication with all your clients. The best part about kerberos is that it is supported by a large number of clients and daemons. You will easily find APIs for integration in almost all popular languages and Operating Systems.

SSH and web servers are kerberised in a straightforward manner with a handful of commands. For APK modules (mobile apps) you can use the Java API (see here) or any other libraries which provide a wrapper interface to kerberos.

I'd written an article about setting up such a server here, you may find it useful since it was setup using a Raspberry Pi. Also refer to this excellent guide giving an overview of all possible ways to integrate kerberos within apps.

In addition to the kerberos server, the same raspberry pi could also serve as a RADIUS server, an NTP server and a common syslog server to gather all the logs of all the daemons across your network. But ensure that you harden it properly. If you need good redundancy, the entire setup can be mirrored very easily as all these protocols natively support mirroring.


self signed root cert can not be verified with openssl - error 18 at 0 depth lookup

I'm answering to my own very newbie 101 question. I had to install root cert so that I could trust it.

I was updating redhat ca after copying my root cert to /etc/pki/tls/certs, but somehow it was not reloaded. I ended up copying the PEM manually to /etc/pki/tls/certs/ca-bundle.crt.


Problems with avoiding JSON hijacking with MVC3's AntiForgeryToken, or similar token validation

This technique was pioneered by Jeremiah Grossman.   This was only an issue because the returned json also contains javascript which could be included into a page via a <script> tag.   Most json responses cannot be abused this way because the same-origin policy forbids javascript from fetching the results.   To patch this issue Google used an unparseable cuft.


GnuPG warning for a signed key with trust level 4

The message says GnuPG could not validate the key issuing a correct signature. With other words, you know that the signature was indeed issued by a given private key, but are not sure who actually issued this key.

Trust in GnuPG is only relevant when validating keys based on certifications in the OpenPGP web of trust, also read up on "What is the exact meaning of this gpg output regarding trust?". The trust level defines how much you put trust in the key owner's certifications on other keys, but requires already validated keys. For example if issued on an already-validated key, trust level four ("full trust"), by default defines all keys certified by the valid and fully trusted key to be also valid.

"Ultimate trust" (level five) is special: it is used as introducer when validating keys, thus makes the key validated and always considers other keys certified by this key as validated. This should never be used on keys not issued by yourself, gpg --edit-key and sign other's keys instead of issuing trust (after verifying the key in fact belongs to that party). If you do not want to issue a public certification, there's also lsign for issuing local signatures that GnuPG does not export when sharing a public key.


Analyzing Network Anomalies for Malicious events

A memory issue can cause a server to BSOD. If your settings for the BSOD are to automatically reboot, then the server reboots.

Some malware might need to load at startup, so the intruder may trigger a reboot in some way.

Read this article:

http://www.clickonf5.org/7848/howto-solve-frequent-restart-shoutdown-computer/

It shows that reboots are not just caused by malicious people, but by many issues. From an operational standpoint, you would want to know what caused the reboot so you can fix it.

Additionally, the advantage to detecting reboots may be "because our industry requires it." This article http://www.nist.gov/itl/csd/monitoring-012412.cfm and NIST SP 800-137 show some mandates and guidlines for continuous monitoring. Since a reboot be a notable event, you'd want to know what caused it.


Check Point SSL Certificate Interception

Generally this is possible because the corporation controls the devices subject to monitoring, therefore they can instruct the devices to trust their own CA certificate.

  To make the PC trust the gateway CA certificate:

  Export the CA certificate from the SmartDashboard (on the HTTPS
  Inspection window of the Security Gateway, or on the HTTPS Inspection > Gateways pane).

  2 . Install the certificate on the user's PC:

  Manually put the certificate file in the user's PC. Click the file and
  follow the wizard instructions to add the certificate to the trusted
  root certificates repository on client machines.

  Use GPO or group policy to distribute the certificate to a large group
  of users. See the documentation for more details.

https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk65123&partition=General&product=HTTPS

They can then intercept the TLS handshake and substitute the certificate with one they generated and signed themselves, and which your device will trust. They can then act as a man-in-the-middle, decrypting your traffic before sending it onto the legitimate destination.

  is my ISP likely doing this as well?

No, your ISP isn't in a position where it has access to your devices, therefore they cannot install their own trusted CA certificate.

Additionally, some clients (eg. some mobile apps and some browsers in some circumstances) will "pin" certificates, meaning they will only accept a certificate signed by a particular CA. In that scenario they won't accept the certificates generated by your company.


during ssh handshaking server introduce itself - does it improve security to change self presentation?

Does configuring system to not present themselves during handshake, increase security?

Yes, service fingerprinting is a first step for an attacker to identify vulnerable systems. It's good advice to not advertise version details of your OS.

  how to configure server to not introduce it's OS version during ssh handshake?

In /etc/ssh/sshd_config you can set the VersionAddendum entry to none or a custom vaue:

VersionAddendum none

(Make sure you restart the SSH daemon afterwards.)


How can I tell if a site is using open SSL, and which version?

You're not able to tell from version info, mostly because you can't guarantee that it's accurate or even available.

Browser plugins are check sites are surfacing that allow you essentially test the exploit to identify if the site is vulnerable and that's really the only way to know for sure.


What are the benefits and risks of various TLS Handshake protocols?

Depending on how you see it, there is one, two, three, or many more "handshakes".

A first distinction is between "SSL-2.0" and "SSL-3.0 and later". The format of records and handshake messages for SSL-2.0 differs a lot from the records and messages used in subsequent protocol versions. Apart from the format and the implemented algorithms, a notable semantic difference between SSL-2.0 and the later protocol versions is that in SSL-2.0, both client and server send lists of cipher suites, and the client chooses, not the server. In later versions, the client sends a list, and the server chooses.

When doing a SSL-3.0+ handshake, the client sends a ClientHello message, and the server responds with a ServerHello. The ClientHello may contain many extensions, which are (by definition) open-ended, and it is up to you to consider whether extensions "change" the handshake or not. In any case, if the client and server agree to resume a session (either they reuse a session ID and remember the past session, or the client sends a session ticket, then you get the abbreviated handshake:

  Client                                                Server

  ClientHello                   -------->
                                                   ServerHello
                                            [ChangeCipherSpec]
                                <--------             Finished
  [ChangeCipherSpec]
  Finished                      -------->
  Application Data              <------->     Application Data

In all other cases, you get the "normal" handshake, that looks like this:

  Client                                               Server

  ClientHello                  -------->
                                                  ServerHello
                                                 Certificate*
                                           ServerKeyExchange*
                                          CertificateRequest*
                               <--------      ServerHelloDone
  Certificate*
  ClientKeyExchange
  CertificateVerify*
  [ChangeCipherSpec]
  Finished                     -------->
                                           [ChangeCipherSpec]
                               <--------             Finished
  Application Data             <------->     Application Data

The "*" above means that the message is not always there. For instance, the server will send a ServerKeyExchange only if the cipher suite calls for such a message ("ECHDE_RSA" implies such a message, while "RSA" alone does not).

So this leads to a number of possible combinations of messages sent or not sent. Moreover, a number of extra RFC define some extra messages, that do not appear in the diagram above; e.g. RFC 5077 defines a new handshake message NewSessionTicket that may occur just before a ChangeCipherSpec from the server. Similarly, RFC 6066 defines the new message types CertificateURL and CertificateStatus. RFC 4680 also defines SupplementalData that both client and server may send to each other.

How you choose to classify all of these features, and whether they induce notable differences, is up to you. Moreover, there cannot be a definitive, exhaustive list of variants, since new extensions that trigger new message types or new handshake flows can always be defined afterwards.


Authenticating Certificate for School Wifi

As the image you shared indicates, this is simply the certificate used for client authentication.

Basically, your device is performing an 802.1X authentication to connect to the network. This uses an EAP method to authenticate to a RADIUS server, most of the common ones establish a TLS tunnel between the client and server to protect the user credentials.

When the EAP supplicant (i.e. client) begins the authentication with the RADIUS server, the server begins by providing it's certificate to the client. The client then needs to determine if it is going to send the credentials to the server.

Since your device is not actually connected to the network until after you authenticate, there are only limited ways it can validate the certificate and server is valid. In the case of your OS, it is prompting you for validation that this is the server you want to send your credentials.

Accepting simply allows your client to continue the authentication process. It is not installing any sort of certificate (CA or otherwise) on your device.

  I don’t know if this is a trusted root certification but what does this certificate enable them to do?

It doesn't allow them to do anything. It allows your client to continue authenticating.


How to determine whether site is secure from common user's point of view?

https/SSL everywhere. Securing just the login is useless, as its trivial to steal session cookies from unsecured connections (see http://codebutler.github.com/firesheep/).

Never send them their password. In a proper designed system, that is impossible anyway (only storing hashed, salted passwords, not the actual password). Yet way too many sites still do that.


Malware Suddenly Uploaded To My Website!

Short version:

However it got there, it's there.  Your first step should be to contain the damage.  I recommend setting up a temporary "site maintenance" page and setting your site to serve that, immediately, while you figure this out.  Otherwise you'll get more blacklisted as the stuff stays out there.
Congratulations, you put malware on Security.StackExchange.  U R HAKR!  More seriously, the amount that you posted is enough to trigger my web gateway's antivirus (it calls it EXP/JS.Expack.GQ) so I and presumably other people can't even read your question.  (I'm posting this through a separate system because I was curious).  If you want people to see your question, I recommend replacing your code blocks with images (e.g., .gif/.png) of the code.
To your original question, the attacker probably abused a php script on your system to upload a command processor, and then used that command processor to insert the obfuscated code that you found.  It's probably lots of other places too, not just index.php.  You're going to need to revert to backup or otherwise recover your site before you can get un-blacklisted by Google.

Long version (or, Incident Recovery When You're the Watering Hole):

This type of code is consistent with what's called a "Watering Hole" attack - the attacker places attack code on web pages hosted by an innocent system.  Web users innocently browse to your innocent system, and end up downloading malware from the hiddden iframe that the attacker put on your site.

Any method of compromising a host can be used to initiate a Watering Hole attack, but (IMHO) the most common is vulnerable web server scripts.  Wordpress is particularly prone to being kicked over; a site I worked got bit by the Tim Thumb fiasco.  Such attacks find some script on the site dumb enough to write a script to the site itself, and the attackers then execute the script they just uploaded in order to make changes throughout the site.

These attacks should be responded to with a combination of file and log timeline forensics.  You have a file 46ZqQVmc.php that seems suspicious - what's the timestamp on that file?  How does it compare to the timestamp on the index.php that was updated?  How many other files in your web root have modification times similar to those two files?  You can find a number of other files compromised in the same way using that correlation.

With those timestamps, take a look at your logs.  Who hit your web site at the time that the 46ZqQVmc.php file showed up?  What URI did they hit?  That might tell you the script that was abused in order to upload the file.  If my experience is any indicator, you can then find hits to the uploaded PHP file that correlate time-wise with the file modification of index.php and any other hacked files.

Once you've correlated file times with web logs, you've also learned the IP address(es) of your attacker.  Now go through the logs and look for everything they did.  You might find references to other files and URIs.

Your end goal in all this is to identify the file they abused to gain access to your system.  In my case, they uploaded an image file with PHP in it, and when they hit it from a web browser they could upload PHP programs as part of the HTTP request and it would run it for them.  They took advantage of a script already on the server called "thumb.php" to do this.  You need to find what script of yours they took advantage of so that you can remove or update it to remove the security hole.

Your cleanup will consist at a minimum of closing the hole they used to get in, and removing the code that they injected into all your files (like index.php).  Once you've done all that, take down your maintenance page, scan yourself with Sucuri, notify Google to scan you.

Traditional wisdom is that there is no such thing as a cleaned system, that the only way to be sure you're secure is to identify the root cause, and then build a new system with that corrected and restore from known good backups.  That's not realistically possible for many people; they don't have backups at all.  The good-ish news is that, if you were in fact hit in the manner I described, the attacker probably didn't bother to try and expand their compromise.  They probably didn't elevate to root privileges, modify system files, or grab password hashes.  (You should change all your passwords anyway, but...)  In a limited scope breach like this, the limited measures I've described may be good enough.

You should also consider additional restrictions once you've cleaned up - file integrity monitor like AIDE, PHP lockdown to disable unnecessary and dangerous functions, restrictive file permissions to block the web server writing to the web root.  It's all dependent on what web apps you're running, look for hardening guides.

Good luck.


WiFi Router, current status of security options?

Many of those are going to be irrelevant to you. As mentioned in a comment, the only important point is that it has WPA2 and AES. Every modern router has this, so from that perspective it doesn't matter what home wifi router you choose.

Generally the differentiation is on non-security features such as the admin interface, management tools etc.


How to encode letters in multipart/form-data to include CR/LF characters?

How are newlines a problem when there is a boundary defined? The thing with this kind of HTTP packet is that it's binary safe, meaning that the entire 0..255 ASCII range can be used with no problem; including newlines and carriage returns. As long as the specified boundary is not encountered, the server or browser will simply see the characters as part of the data and not as any separator.

Only if an attacker can control the name in the content-disposition header, you would need to strip newlines there. Or if he can guess the boundary to be used, you should make sure the boundary is dynamic or is simply stripped.


No. Client-side validation can be useful for performance or UX reasons, but it is not a security feature and its lack has no security impact whatsoever. Indeed, client-side validation can provide a false sense of security, so purely from a security perspective, I prefer to not see it.

Now, if the server is not processing the requests correctly - if adding new or malformed parameters can cause unexpected behavior, edit content that isn't escaped correctly in the response, or otherwise potentially have a security impact - that's of course something I would call out. The attack vector and mitigation wouldn't have anything to do with that client-side form though; the repro steps would simply be a URL to paste into the address bar of the browser, or perhaps use tools like curl or Burp Suite.


Which all ports are in danger and needs to be closed with immediate attention?

Without knowing anything about your server, I'd classify the following ports as a danger:

53/tcp    open     domain
53/udp   open          domain?

Most people shouldn't be running publicly accessible DNS servers.  If it's not locked down properly, your server can be hijacked to participate in a reflected denial-of-service attack.

3306/tcp  open     mysql

You should never expose your database server to the Internet at large.

2077/tcp  open     unknown
2078/tcp  open     unknown
2082/tcp  open     infowave
2083/tcp  open     radsec
2086/tcp  open     gnunet
2087/tcp  open     eli
2095/tcp  open     nbx-ser
2096/tcp  open     nbx-dir

22816/tcp open     unknown

These ports don't correspond to any standard service.  Find out what's got them open and firewall it or shut it down.

I'd classify these as potentially problematic:

21/tcp    open     ftp

You shouldn't be using FTP these days.  It transfers credentials in the clear, it's a pain to make it work with firewalls, and in general it's an old, crufty protocol.  Shut your FTP server down and do any file serving over HTTP, HTTPS, or task-specific protocol.

25/tcp    open     smtp

If your SMTP server isn't configured right, you can find it being used as a spam relay.

The rest of the open ports may or may not be a problem, depending on the purpose of the server.


The first thing that comes to mind from a network security stand point is ensuring you have a solid DMZ in place. The DMZ is the ideal network location for you to separate your internal home devices from your devices that you would like to speak directly to the internet.

Your network stack would look something like this:

ISP
MODEM
Firewall/Router (Or firewall then router if using separate equipment)
DMZ
Firewall (same options as number 3)
Your internal network

By using this kind of set up, you reduce your risk of internal impact to your private network devices which should NOT serve information to the internet. Even if your DMZ is compromised, attackers would then need to traverse an additional firewall and router system to get to any of your personal data.

Now, you can technically use the Fritz!Box to setup a DMZ and have a single router configuration. This would be a cheaper alternate to setting up two different routers and having to configure your network hops from router to router. Instructions are below:

https://en.avm.de/service/fritzbox/fritzbox-7581/knowledge-base/publication/show/131_Setting-up-a-DMZ-with-the-FRITZ-Box/

My only concern is that most consumer grade routers today fail security tests regularly, and I'm not sure that you'd want one single point of compromise for your entire network. Then again, I like tinfoil hats a lot and they tend to keep me employed!

Finally, opening yourself up to Tor traffic can be exciting, but it also invites scrutiny from governments that you may not want. You are also allowing illicit traffic to flow through your network, even if that's something you're otherwise against. There are many ethical issues to sort through as you become a member of the Tor relay. That's not to say all people who work on Tor are bad (in fact there are many legitimate uses), but it is still something to consider.


How vulnerable are devices on my home WiFi?

I don't know about this specific camera model but IoT cameras were often in the press in the last years because of the many security issues. This includes cameras from Foscam.

Not all attacks against IoT devices need direct access to the device, i.e. port forwarding through the router. Especially with CSRF attacks the browser could be used as a trampoline to hijack internal devices from outside. All you need to do is visit some site which contains malicious code to hijack the device - this could even by done by an advertisement embedded into a site with high reputation, i.e. malvertising. And if you are using google to search for IoT camera CSRF or even Foscam CSRF you get lots of hits so the risk looks real.

One of the hits you get when search for concrete vulnerabilities is probably "All your video are belong to us. The Foscam webcam" which explains how to hijack a Foscam device which is only visible in the internal network from outside via CSRF and make it upload the captured images to an external server. This should be scary enough that you don't want to have these cameras in the internal network.

And, if you consider such attacks only theoretical you might have a closer looks at reports like hijacking 4.5 million routers in brazil with CSRF. Such attacks are real and even if the attacker is not interested in getting the images taking from the camera he might be interested to use the camera to attack other systems, both in your internal network and also external systems as part of a botnet consisting of IoT cameras.


Encryption in case of distributed architecture

I think you're looking for SSL Termination, what basically happens is that the load balancer handles all the TLS/SSL process and forwards the requests to the end servers. This approach aims to streamline the implementation and management of SSL connections, imagine a load balancer serving 20 back end servers, it would require 20 machines to be able to handle connections from the same domain, and if you decide to upgrade your certificates thats a lot of work. If you however, implement it at the load balancer, all the back end servers need not to worry about this process.

  Web Client --> HTTPS --> Load Balancer --> HTTP --> Backend Servers

One thing to consider is that you would be trusting that the connection between your load balancer and your back end servers is secure, which for most server schemas isn't really a problem.

Here is an article on how to implement this for NginX


What are the downsides of BrowserID/Persona compared to OpenID/OAuth/Facebook?

I like the idea, but I too have many questions left open. Please do not see this as any form of bashing, because I wrote it trying to apply my authentication experience to this new scheme.
I am concerned about (in no particular order) :

Unauthorized use of the private key
Rich client support (Outlook, Notes, etc.)
Using from multiple computers
Private key protection or encryption (on the client)
Authentication of key generation requests
Privacy

Details below. First a one line summary (in bold italic) and some clarifications.
1. Unauthorized use of the private key
The private key will be protected by the client, with varying degrees of security.
I am worried that any the private key will be used without my consent. When trying to authenticate, a signing operation will take place. I must be prompted before it is used, or else a rogue script could get my browser to sign a logon ticket and submit it. Rogue script could come from a widget, add or other XSS. Implementation of this mechanism will vary in every browser, and even on different platforms for the same browser, or different versions, etc. With a somewhat inconsistent visual, users are at a greater risk to being lured to approve a logon request.
2. Rich client support (Outlook, Notes, etc.)
It was desinged to work with web mail accounts. Enterprise "fat" mail clients are somewhat left behind.
For Browser ID to work, you need a browser that supports it. In the meantime, some browserid.org issued "JavaScript shim that implements the missing functionality using standard HTML5 techniques and cryptographic routines implemented in JavaScript".
Users in a corporate environment who use fat mail client (Outlook, Notes, Thunderbird) will be late adopters, because the protocol will have to be implemented in those clients too. Not to mention that Outlook does not share a keystore with Firefox, or Thunderbird with IE.
3. Using from multiple computers
It leads to a proliferation of private keys, because the scheme does not to have a central authority.
And there is a mobility problem. I will have to register (generate a private key) for every computer I use. How will I go about deleting my private key in an internet kiosk, or a borrowed computer ? Even with a single computer, how will I revoke a key stored in a stolen computer ? Since for a single user, multiple signature keys are valid (because each of my computers have its own valid private key), from the service provider point of view, any access token signed by a known authority must be valid.
4. Private key protection or encryption (on the client)
Access to the key must be authenticated, which brings passwords back in the picture.
It can protected by a password (limiting its malicious reuse), but if I ever change my password somewhere, it will not synchronize unless I use some browser/cloud based sync network. Having a password to remember somewhat defeats the purpose of this scheme. Chances are the same password will be used to secure every key, much like the same password is used now to authenticate to multiple websites.
5. Authentication of key generation requests
There is a gap between the access request and key generation, wich an attacker could use for phishing.
It is unclear to me how the email provider/certificate authority will handle CSRF issues. How will they know that a request for key generation is legitimate ? Will my spam folder be filled with certificate generation requests ? Or will key issued only with DKIM email servers ? What if the request was intercepted on its SMTP way to the server, could it be modified ?
6. Privacy
Using a  tag allows browserid.org to break the same origin policy.
And using a script tag to include the browserid.js allows them to bypass the same origin policy. BrowserID.org will (have the power to) know about every logon attempt you make. Or you will have to host the script yourself (assuming it is self contained), and upgrade it if/when security flaws will be identified in it.


How can an account be accessed even though two-step authentication?

There are different possibilities from the top of my head:

the identifier of a legitimate device has been compromised (by a MITM with a downgrade attack, for example) and used to identify as such device,
the mobile phone has been compromised as a whole (forwarding and hiding/deleting SMS and emails),
SS7-based attack on your mobile number in combination with a compromised email account.


What is a "Trailing Host Header", and how can I test for it?

The Host-header is used by the client to indicate with which server name it wants to speak. Multiple websites may be served off from a single IP address.
In the HTTP protocol, data may be sent in multiple chunks. This is especially useful if the server does not know the size of the data before completing the request (e. g. a live stream or a web application that starts to send some results while still working on the rest).
See 3.6.1 Chunked Transfer Coding for details:

The chunk-size field is a string of hex digits indicating the size of the chunk. The chunked encoding is ended by any chunk whose size is zero, followed by the trailer, which is terminated by an empty line.
The trailer allows the sender to include additional HTTP header fields at the end of the message.

Even if a client is uploading something of unknown size, it will know the target location at the time, it opened the connection. Therefore it does make no sense to put the Host header into the trailing section behind the data.
The situation may be exploitable, if the request is handled by a reverse proxy (aka web application firewall) that handles access rules: The reversed proxy may see one of the host header, but the web application may see the other one.


This 2013 article analyses retention time for several DRAM chips. Among the relevant information, one may list the following:

Retention time depends on a lot of things, including the values of neighbouring bits. A DRAM bit is a potential well, and it loses its contents by moving charges from or into neighbouring areas, so whether there is room in these neighbours matters.
Temperature is very important for retention time (which is why cold-boot attacks insist on cold: if you plunge the machine in liquid nitrogen, you can keep the charges in place for substantially longer).
At room temperature, typical retention time is counted in milliseconds, at best a few seconds, and, more importantly, the discharge is exponential in nature (it goes in e-Ct for some constant C), as could be expected (capacitors also work that way). So the remaining charge after 2 minutes will be half that after 1 minute; after 10 minutes you are down to a thousandth of the initial charge; after 20 minutes, a millionth; after 30 minutes, a billionth.

To sum up: 24 hours... forget it. You won't find meaningful data in DRAM that has been kept unpowered, at room temperature, after 24 hours (even if the room is, say, in Canada).

This is for DRAM, where a stored bit can be envisioned as a charged capacitor. This is the kind of RAM commonly found in PC for the last 20 years.

There also exists SRAM, where each bit is stored as the current state of a bistable circuit that consists in 6 transistors. SRAM is substantially faster than DRAM; it is also a lot more expensive. In PC, SRAM is used for cache (usually integrated in the CPU). Without power, SRAM loses any trace of its contents within microseconds.

There are some stories about bits being "burned" into RAM when the same value is stored for a long time in a specific emplacement in a chip. To the best of my knowledge, these stories are exactly that: stories. They come from "thought by analogy", by people who think of RAM in the same way as they think about CRT displays (which could have "burn-in" effects, hence the development of "screensavers"). I am not aware of any case where such stories were ever substantiated.

But fears and doubts are powerful forces that cannot always be dispelled by the strongest logic.


Integrity of downloaded Oracle JDK (/software in general)

AFAIK, some of them are in countries, where single entity (gov) can
  covertly do whatever it wants on their machines.

Yes, pretty many countries are like that today.

Sadly, concerning governments, the CA system is not (and never was) secure.

CAs are still good for preventing some people and organisations from attacking, just not all.


Simply, flow is a non-payload detection rule option utilizing the Stream preprocessor (formerly Stream5, Stream4).  I recommend reading the following documentation:

Snort Manual § 3.6.9
Stream5 README File

To answer your question:

  For example, flow:established is detecting only for packets with sessions connected.

I'd like to expand on this.  TCP connections use a 3-way handshake (3WHS).  The client sends a SYN, the server responds with a SYN+ACK, and then the client replies with an ACK.

Image from: http://blog.wangyizhe.net/2015/10/TCP-3-way-Handshake/

When using flow:established in a rule, you're telling Snort not to bother looking at [typically] the first three packets in a TCP stream.  This is done because normally there is no content (Application Data) inside.

When not to use established in your flow option:

When writing a signature that does not use TCP (e.g. UDP, ICMP, IP)
When writing a signature that is designed to target packets inside the 3WHS.

  Then, the server is rejecting packets to received after the session is disconnected?

Remember, Snort is not a server; it is a Network Intrusion Prevention/Detection System (NIPS/NIDS).  The only way it will reject packets is if you have it configured and running in an inline configuration (NIPS).  If not, it can only observe traffic and cannot actively reject or drop packets.

Assuming you had Snort configured and running in inline mode, if you were to write a rule like:

drop tcp any any -> any any (msg:"Dropping packets"; flow:established; sid:1; rev:1; )

... The rule would fire on any TCP packet that was seen after the initial 3WHS.  This would appear to both the client and server as a successful connection, but no data would be transferred, because Snort would be dropping packets.

Remember that Snort is a detection engine, so don't think of it in terms of sending/receiving data or initiating/establishing connections.  Think of it as a passive observer (or in the case of an IPS, a bouncer at a nightclub).

For more information on flow or the Stream preprocessor, please read the documentation I linked to above.

Hope this answers your question!


How to tell my HTTPS connection to a site uses PFS?

In Google Chrome:

click on the padlock icon:

click on "Details":

click on reload:

In the Security Panel, click on the URL under "Main Origin":

look at value of "Key Exchange" under the "Connection" section:

If the key exchange begins with "ECDHE" or "CECPQ1"1 then you have PFS.

In Mozilla Firefox:

click on the padlock icon:

click on the expander thingy on the right side of the popup:

click on "More Information" on the bottom side of the popup:

look at name of cipher suite in Page Info popup window:

If the name of the cipher suite begins with TLS_DHE_ or TLS_ECDHE then you have PFS.

I did not find a way to get Microsoft Edge to divulge the used TLS cipher suite in the UI - you need to sniff the traffic with wireShark or equivalent.

I don't have a Safari available right now, but I'll add that later if I find a way to the Safari to display the cipher suite.

1 - https://security.googleblog.com/2016/07/experimenting-with-post-quantum.html


Open source video conferencing software with encryption

Jitsi offers video chat, comes with OTR/SRTP/ZRTP.
https://jitsi.org/
The docs say that it can do multi-user video
https://jitsi.org/Projects/JitsiVideobridge

I have only tried the chat and phone function, they work very well


Well, yes, if you live in the Care Bears Wonderland then nothing bad can happen. Unfortunately, in what is colloquially and pompously known as the Real World™, there are Bad People. Evildoers. Wicked individuals who like to spy and eavesdrop and alter the nice data packets.

SSL (now known as TLS) applies encryption to prevent spying, integrity checks to reliably detect alterations, and authentication to prevent impersonation. The encryption part is only against spying.

If all your data is public, then you don't really need encryption, but you may still want the other characteristics of SSL, so that users know that they are connecting to the genuine site, and that the pages and documents they obtain from the site have not been altered in transit.


Connection not secure when using a proxy

Your school may be one that employs a MITM-style SSL inspection. In the InfoSec community, this is highly frowned upon. In corporations it is expected. The normal purpose for this type of technology is for DLP inspection. There generally is not a reason for the school to be doing this.

The best way to troubleshoot this issue is to navigate to one of the affected pages and look at the certificate chain. The certificate chain should consist of an outside CA (Internal CA's are redflags that your data is being decrypted). I would then take that certificate chain and compare it to a computer outside the school's network. If they match, it may be another issue at hand (Such as revocation lists being blocked by the proxy). Otherwise, it's wise to use a VPN connection to protect your data when you are on the school's network.


Should I return an HSTS header for 404 error pages?

Suppose attacker tricks victim to click on link to your site, browser uses http, attacker in strong network position intercepts and sends malicious content and makes victim believe content came from your site.

How would HSTS help? If the victim visited your site before, their browser has an HSTS "flag" for the domain, and clicking the link would make the browser use https instead, foiling the attack. But only if the victim has visited the site before!

What about victims who did not visit the site before, or visited the site too long ago? This is what HSTS Preload is for. I recommend adding your site to HSTS Preload list. This would foil the attack regardless of presence of HSTS header on 404 error page.

Note, HSTS on 404 error page doesn't affect the attack as described. Whether the link provided by attacker leads to 404 or not doesn't matter - the attacker can intercept and replace the response either way. What matters is whether this browser has visited your site before (within the time limit) or not, and whether you have HSTS Preload (and updated browser) or not.

With nginx webserver, there is a way to add HSTS response header to error pages too, the optional "always" argument to "add_header". I don't know how to do that with IIS or whether it's even possible with IIS, but maybe it is. In your place, I would fix this, but I don't see how it's a security problem.


Possible public/private identity recovery after compromise without a centeral authority?

You could try to mimic Certificate Revocation Lists. That means that each member of the network could publish its public key on a site they manage. But as you have no global authority, I cannot imagine a way to certify the current public key. Said differently, if an attacker manages to hack the site displaying the public key, they could impersonate the user on the network by presenting a new key.

If there were out of band ways of exchanging information (phone ?) we could imagine that each current public key should be signed by another user from the network. In that case, the attacker should hack more than one site to be able to impersonate a single user, but it would lead to rather complex processes...


How I Could Have Hacked Any Instagram Account - The Zero Hack

Can someone explain how this was possible

It was possible due to a lack of rate-limiting on the action/request. As you said, it could be brute-forced hence.
Instagram has now patched this issue. I haven't seen any official publication on the mitigation measures, but a quick visit to Instagram's Password Reset Page reveals the [intended] user is now sent a link.

and how to mitigate it?

You could rate-limit the action/request - not only by IP address but actually upon the action itself. However, this would pose a potential DOS(Denial of Service) attack - hence why Instagram probably did not limit it as such in the first place.
For one, given it is a 6 digit code given to the user you could significantly reduce the rate-limiting threshold per IP address (i.e. from 200 to 20) to increase significantly the cost of the attack.
But put simply, the 6 digit code itself is flawed. Although the DOS attack may be viewed as 'unlikely', it carries relatively small cost given the potential gains/motives for the attacker, so it should be mitigated.
Hence, as instagram have - the easiest solution is to verify the user via more secure means, e.g.:
Send a link to the user (via external, previously established, communication channels) and then get them to input the code at this unique link.
Make the code 10 digits alphanumeric and set a 30 minute expiration & rate-limit the number of codes that can be issued repeatedly.
etc.


How to rate CVSS3's "Privileges Required" when an attacker can create an account?

First of all, bigger PR makes lower risk ratings, it will not increase scores.

At that https://www.first.org/cvss/cvss-v3-guide.pdf guide (page 18) low privilege will be 0.62 and high will be 0.27, they will be used at multiplication.

You can calculate V3 scores at https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator to see results.

To determining your scenario we need to ask one question, "is anyone can register to this forum?". Possible results listed & explained below.

"No, there is forum admins and they accepts users": Someone gives authorization to users so this is a low PR.
"Yes, anyone can register simply": No-one reviews users and gives additional authorization so this is a none


Simple Windows 7 honeypot: is this safe?

Deliberately opening your computer for attack is not safe.
You presume the attacker is interested in your shared folder, much more likely with a connection to the machine they will choose other attack avenue.
A better solution is to install a honeypot on the pc.


Can I get in trouble for legitimate mistakes in bug bounty testing?

I have a computer with a cloud company where I receive between 300 and 1,000 hacker hits a day. I keep it as a test bed (I wouldn't want it for a production service, although they main access port 25--for free mail relay...)

I talked with the ISP to see whether we could do something about it and they said there was nothing they could do that would be any different than my existing protections.

I'm pretty such that your little mistake was pretty much transparent. Your ISP may have flagged your computer, but I would not see how they could know that your traffic was illegitimate since these were legitimate, albeit repeated, hits anyway.

On my systems, I have ways to detect that someone is trying an attack and block such IPs for a while. I guess that would be the worst you would get. Nothing to worry about, really.


DNS Poisoning - How to edit the "list" it in the target server?

One option is DNS cache poisoning - compromising a DNS server and changing entries there (making security.stackexchange.com point to the IP used by facebook.com). Clients of this server and other DNS servers, that cache the information from the server you compromised, will cache the incorrect entry and will redirect its users to facebook.com. But if the domains are protected by DNSSEC this attack would be most likely unsuccessful.

Another option is DNS hijacking - forcing a client use your malicious DNS server instead of a genuine one. Done by manipulating the victim host's TCP/IP settings.

Probably needless to say that doing any of this is entering the black-hat (or at least grey-hat) territory as you need to attack vulnerable servers/clients.

Some blogs about vectors of DNS-related attacks, if that was what you're interested in:

https://www.silicondiscourse.com/2017/03/home-routers-and-dns-attack-vectors/

https://blog.malwarebytes.com/cybercrime/2015/09/dns-hijacks-what-to-look-for/


OpenID Connect Web Message Response Mode and XSS

Any response modes for SPAs won't prevent response parameter leakage via XSS.

However, you can use PKCE and store the PKCE code_verifier in memory, then only your JS caller can exchange given authorization code with access token.


Is SSL-strip still viable as a method of attack?

Your base assumption, that all browsers use HTTPS by default, is incorrect.

If you click a link, it uses the protocol specified in the link. The internet is full of HTTP links.

If you enter a URL in the address bar, the browser makes a plain HTTP request first. Trying HTTPS first would not help, since a MITM could just not respond to that request, forcing the browser to try plain HTTP instead.

So yes, SSL-strip is still a very real threat that can not be solved by browsers alone. To fix it, you need HSTS.


Something is changing my hosts file without asking

Use Process Monitor with a filter to watch the hosts file. Run it long enough and you will see everything that changes the file.

http://technet.microsoft.com/en-us/sysinternals/bb896645


Thousands of files (png, pdf, tex, java, cpp, etc.) deleted on Mac OS X Yosemite

Were you online at the time? I realise that this may be very obvious, but if your mac is linked to any online file sharing site such as dropbox or icloud then deleting files on that site (or another computer linked to the same sharing space) may result in local files being deleted at the next 'sync'. Also, systems such as dropbox have a history mechanism for retrieving lost files if you need them back. Of course git repo deletions will reflect locally if you do various git commands (again, you've probably thought of this).

Now you've wiped the system it may be quite difficult to tell what is happening, but it would have been worth checking the startup programs, which processes were running, the permissions (and therefore the require permissions to delete) of the files that were deleted.

Have you got a time machine backup? Have you thought about how much you will trust that backup?


dig returns different MX record, can anyone explain why?

I've run into this problem before.  In my case the domain in question belonged to a client (let's call him 'Joe'), and the client had his own domain name (let's call it 'joescompany.com'), and the client had an email address at the domain (let's call it 'joe@joescompany.com').  Joe also had ISP service with a local ISP (let's call them joesisp.com).
Joe conveniently used joesisp.com's DNS server to host the DNS for joescompany.com.  He also used joesisp.com's mail server to host email for joescompany.com.  It just so happened that I also used joesisp.com for my ISP service as well.
Then, one day, Joe decided to move his joescompany.com domain away from joesisp.com.  He contracted with another provider to host the DNS for joescompany.com, and he used that company to host his email as well.  But, Joe didn't tell joesisp.com that he did this.  So, as far as joesisp.com was concerned, they thought they were still hosting the DNS for joescompany.com, and hosting mail for joescompany.com as well.
This didn't impact most people that sent Joe mail.  Mail sent to Joe by most senders arrived at Joe's new provider's mail server just fine.  But, when I would send mail to Joe it would get delivered to Joe's old mail server at joesisp.com.  That's because I was using joesisp.com as my ISP, and therefore I was using joesisp.com DNS servers, which (incorrectly) pointed the MX record for joescompany.com to their own MX servers.  All other DNS servers correctly pointed the MX records for joescompany.com to Joe's new MX servers, but joesisp.com's DNS servers still pointed to Joe's old MX servers.


Is it safe to expose an SHA1 hash of an encryption key?

Revealing the hash of the key may or may not be safe, depending on what you do with it. In your case, you have a key K, you show h(K) for some hash function (say SHA-1), and you also show e(K,M) for some encryption algorithm e (e.g. AES) and message M. This is safe only inasmuch as e is "different" from h, which is an ill-defined property.

For instance, imagine an encryption algorithm defined the following way: for message M and key K, hash K with SHA-1, then use the first 128 bits of the SHA-1 output with AES to process the message M. As far as encryption systems go, this one is rather good; it is as good as "raw AES" but it also accepts keys of arbitrary length. However, if you reveal SHA-1(K) then it becomes trivial to break it, even though you did not reveal K itself.

For what you want to do, you need some isolation layer between what you show for key indexation, and the encryption system. A hash function does not provide such an isolation layer "generically" between its input and its output because the output can be computed efficiently from the input (that's what the hash function is about). On the other hand, for a "good" hash function, there is no known way to compute half of the output by knowing just the other half; otherwise, fast attacks against preimage resistance would work. This yields the following scheme: from your key K, compute SHA-256(K). Split the 256-bit output into two 128-bit halves. Use the first half for indexing (you show it), and the second half for actual encryption.


Design of a state machine model to solve conflict of interest in Computer Security

Unless you mean something very specific by "state machine model", there is no reason why you couldn't model conflict of interest using a state machine. The Chinese Wall itself can be easily represented as a state-machine, following the traditional BLP approach:

a state is defined by the set of current accesses, a function associating each object to a company dataset, and a function associating each company dataset to a conflict-of-interest class.
The transition function takes a state and an access, and if the access request is not in conflict with a current access, it is added, otherwise the access is denied.

Ravi Sandhu actually proposed an enforcement of the Chinese Wall model using a lattice-based model,  and some of my PhD work was to define some general state-machine model for access control systems, including the Chinese Wall. The section 3.2 of this paper can give you a formal definition of the CW using a state-machine.

I hope that helps, and I can bring more clarifications if wanted.


It depends what are your exact needs.

Solution A: This is the preferred one when executing commands as a privileged user (maybe root, maybe another account which has more privileges than a standard user). This allows to define a policy describing the exact actions to be allowed, so that this access cannot be abused by the unprivileged user (either maliciously or mistakenly).
Solution B: In term of privileges it is strictly equivalent to providing you an interactive shell as nologinuser (with a better audit and password management than actually giving you the target account password).

As per your message, I have the impression that there don't seem any real problem in handing you a shell as nologinuser, flexibility however might be an issue (you don't want to have to call the admin each time you want a new command, option or file added to the sudoers file), and your main concern is that no action should be done as root.

If my understanding of your message is correct, I would go for the solution B.

You are right in your conclusion that allowing user_1 to execute commands as user_2 using sudo does not provide any root privileges to user_1, either directly or indirectly.

People often have the wrong impression that sudo provides super-powers. While its most common use is indeed to run commands as root, it can also be used with the reverse effect to decrease the privileges of a command.

Personally I often use sudo to execute a command as a lower-privileged user (a daemon, a file-transfer utility, etc.). In such cases there is no point in restricting the executable commands, just define which users can run command as this nologinuser and under which conditions (password required or not, environment variables to keep, etc.) and you will be fine.


Salt doesn't protect you against a lone attacker who is only after one password. An attacker who just wants to break one password will calculate hash(salt + guess) instead of hash(guess) (if the password scheme is hash(salt+password)).

Salt helps if the attacker wants to break many passwords. This is usually the case. Sometimes the attacker is attacking a site and wants to break into an account on that site, any account. Without a salt, most of the attacker's work can be used for all accounts, so she can test each of her attempts against all accounts at once. With a correctly-chosen salt (i.e. if no two accounts have the same salt), the attacker has to start over for each hashed password.

Furthermore, in a sense, all password cracking attempts are attempting to crack all accounts passwords at once. That's because hashes can be precomputed; all it takes is for someone to generate a table of hashes — or more efficiently, a rainbow table — and that initial work can be distributed to multiple attackers who can use it on any account database that uses the same password hashing algorithm. Again, salt makes these precomputations useless.

A brute-force password attack can be summarized like this:

Make any precomputation that the attacker deems useful, such as building a rainbow table (which is an efficient way to represent a table mapping hashes to common passwords).
For every one of the n accounts that the attacker is interested in breaking in, and for every one of the p password guesses that the attacker includes in her dictionary, test whether hash(guess[i]) = hashed_password[j].

In a naive approach, the second step requires n × p hash computations to try all guesses against all accounts. However, if the first step already calculated all the possible hashes, then the second step requires no hash computation at all, just testing whether each hashed_password is in the precomputed database, so the attack requires just n table lookups (this can even be sped up, but we've already gone from n x p slow computations¹ down to n table lookups).

If each password has a different salt, then in order to be helpful, the precomputation would have to include an entry for every possible salt value. If the salt is large enough, the precomputation is infeasible. If the precomputation doesn't take the salt into account, it won't be useful to speed up the second step, because any cryptographic hash function “mixes” its input: knowing the hash of UIOQWHHXpassword doesn't help compute the hash of NUIASZNApassword. Even to attack a single account, the attacker needs to perform p hash computations to try all guesses, already an improvement on the single table lookup that would be sufficient if the attacker has a precomputed dictionary.

¹  A password should not be stored as a hash such as SHA-1, but using a slower hash function such as bcrypt or scrypt or PBKDF2.


You can have a look at Script Defender, ScriptSafe and ScriptBlock Chrome extensions. It looks like they can do what you are asking for.

But the JavaScript issue you are talking about is only the tip of the iceberg.  Protecting yourself against ransomware is much more complicated than this.

At a glance, here is what you can do :

If you are using Windows, you can use group policies to prevent the launch of executables from certain directories.
You can block or limit access to Tor IP addresses.
You can block or limit access (read only) to network shares.
You can filter spam and malicious attachments.
You must backup files regularly and you have to make sure to not overwrite a good backup with a cryptolocked one.

Source : Calyptix blog


Are malicious scripts in batch files detected by antiviruses?

It depends what's in it. If it finds del /F /S /Q C:\* inside a Windows batch file, sure, some AVs might flag it up as suspicious. If it's a byte-for-byte copy of a known malicious script, sure, some AVs might catch it.

In general, batch scripts are too variable in order to write a working malicious script detector that catches new or "custom" malware scripts. You're likely to see the AV catching anything particularly prolific, but almost certainly not anything new or custom.

Don't rely on your AV for protection, even if the sales guy told you it's the best protection money can buy. It's a last line of defence at best, and is usually only good for saving you time by preventing the most basic attacks, giving you the ability to prioritise your resources into dealing with the more targeted attacks.


Why does an overload of requests give one root access all of a sudden?

There's this saying that using a DDOS-attack, people first attack a server using millions of concurrent requests and by doing that they miraculously gain access to the server.

I think with "this saying" you refer to the recent attack at Talk Talk. There were a lot of miscommunication (like talking about "sequential attack" instead of SQL injection) and part of this were claims, that the break-in happened because of a DDoS attack. From The Register:

  The telecommunications firm previously confused security experts by stating that the customers' data may have been compromised via a Distributed Denial of Service (DDoS) attack which had targeted the company's website.

This was later rectified and made clear that it might be that a DDoS attack was used to distract from the real attack but it might have been unrelated too.
But, false information live on for a long time, sometimes in a form of "this saying" where the original source of the false information is no longer known.

To make it clear: a (D)DoS attack might be used as a distraction for another attack but (D)DoS by itself is not able to give access to data.


It would be safer to user OpenID if the site being logged in to does not support SSL than using a username and password.  As long as the OpenID provider supplies SSL, then all that will be sent in the clear (ie, that a man in the middle could get) would be the submission of the ticket indicating that you are who you say you are to the server.

It would only be useful to someone trying to compromise your account on the unsecured site that you are logging in to.  Depending on configuration, it is likely that they would not be able to reuse the ticket to log in in the future as well, where as a username and password combination could be used indefinitely in to the future.


Is it worth it to get paid anti-virus software?

Whether an antivirus is free or not has almost no correlation with its quality. The theory is that when an antivirus is expensive, then the vendors have more money to spend on maintaining the antivirus, and, given the theoretical impossibility to reliably distinguish virus/malware from non-hostile code, an antivirus can be effective only if it is continuously tuned and augmented, on a daily basis.

The theory breaks down on two points:

That the paid vendor makes money does not mean that he wishes to spend it on making a good antivirus. The ultimate goal of any commercial venture is to make a profit, so the vendor will prefer, all other things being equal, to pocket the money rather than spending it on exhausting antivirus maintenance. In theory, market pressure should evict antivirus companies of poor quality; however, it is known that the software industry is full of de facto local monopolies because of technical details (switching from one software to another incurs a noticeable cost, so competition is not fully effective at lowering prices).
The free vendor may be sponsored. An example is Microsoft's Security Essentials: it is in the best interest of Microsoft that Windows users don't get bogged down by malware, so they fund the development and maintenance of a good antivirus that they then give for free (it is now included in Windows 8, which is why there is no separate "Windows 8" download).
Banks sometimes sponsor antivirus packages for their online banking customers, since it is in their interests to ensure the security of their customer's computer, as the bank may be liable for some or all of any losses.
Either way, maintaining an antivirus is labour intensive and security engineers must be paid somehow. Free things are not actually free to create.

It may be possible that any specific third-party non-free antivirus offers some extra functionality which, from your point of view, makes it worth the cost; however, if you don't see it by yourself, then chances are that a free antivirus will be fine for you. Potential distinguishing qualities include ease of deployment in large infrastructure, scalable email scanning on the mail server, and other business-oriented features which are usually not relevant for home users.


First of all you need to understand how things actually work, so take a look here: NAT. This is how your router currently makes internet communication for all your hosts possible.

So, everything is behind a NAT, and that's exactly why you can't access any host using your public IP address. If you want a machine inside your private home network to be publicly available (I mean its services) you would have to give it access to it. In order to do that you would have either to forward some ports from your router to a specific machine inside your network or add the whole machine to the DMZ.

Example 1: I run a webserver at 192.168.1.30:80, so in order to make it accessible from the outside (using my public IP) I need to add a forwarding rule into my router configuration, so that port 80 would be "redirected" to 192.168.1.30:80. So if someone was to browse to http://my_public_ip:80 (you don't have to actually type ":80" here), his request would arrive to my router and it would be forwarded to my 192.168.1.30 machine, eventually showing whatever web page I was running on it. The same applies to every other service you want to make accessible to the public, let's say a FTP server. You can forward specific ports or ranges of them. Sample image:

Example 2: As you realise the above scenario is not always practical. Sometimes you just want to make an entire machine/internal IP the default receiver of all outside requests. This is where the DMZ comes in. If I want every outside request to bypass my router and always arrive to a specific host I would add its IP (eg 192.168.1.123) to my DMZ. Sample image:

Take a look at this question too, for more insights concerning the use of DMZ. Don't be afraid to use it for your purposes though.

As you realise both of the above configurations are done inside your router interface.


What are the risks of using TLS 1.0 for web applications?

This version of the SSL protocol, was officially release in late 1995 by Netscape after the discovery of serious vulnerabilities in the previous version (SSLv2). It is, therefore, obsolete, and it contains, as well, various flaws. For instance:

No support for SHA256, SHA384 and AEAD (Authenticated Encryption with Associated Data) with GCM ciphers.
No Elliptic Curve (EC) support and therefore no Forward Secrecy (FS).
More recently, in October of 2014, it's vulnerable to a new attack named POODLE (Padding Oracle On Downgrade Legacy Encryption). Padding Oracle attacks surfaced in 2001 and explore the fact that [only] in CBC (Cipher Block Chaining) mode, the padding is not protected by the integrity validation mechanisms of TLS -- i.e. MAC (Message Authentication Code). A malicious person can, thus, perform a Man-In-The-Middle (MITM) attack and force the downgrade of the protocol version, which some browsers voluntarily accept. This type of protocol negotiation is needed to synchronize both parties.

If the user becomes the victim of a MITM attack, an attacker can simply use the trust that the user has in the server to create a phishing page, and possibly steal their credentials or some other sensitive information from the company.


Does a virtualised Windows machine without internet access need (security) updates?

I agree with mootmoot, there is no such thing as a closed system if it talks to other machines/there is more than one person accessing it.

You could have a problem if someone breaches the xen server, if someone gets the keys to the vpn, if someone walks up to the host machine with a usb stick...

The vm is in a relatively isolated position, but there are still IO channels hooked up to it and an IO channel is always a potential attack vector.

Update it after you've backed it up. More security is better.


What are the security implications of net.ipv4.conf.eth0.route_localnet=1 / route_localnet?

The documentation for this options shows the following:

route_localnet - BOOLEAN
    Do not consider loopback addresses as martian source or destination
    while routing. This enables the use of 127/8 for local routing purposes.
    default FALSE

In essence it tells the kernel not to treat local routing for as a danger and refuse it. As long as net.ipv4.ip_forward is 0 you shouldn't need to change route_localnet. In most cases you only need this when you do some PREROUTING and/or FORWARD with iptables.

The security risk is limited if this isn't on a public facing network interface and otherwise you want to make sure ingress and egress filtering is done correctly. This to reduce the effects of spoofed traffic.


Does storing all the passwords a user has ever used create a vulnerability in the broader password environment?

Just to be clear, they shouldn't be storing previous passwords, but hashes, preferably salted. Storing a password in plaintext is a no-no.
Storing hashes for the last few passwords may be reasonable although debatable. Storing the whole history sounds overkill. You are wasting storage in a vain attempt to protect people from themselves.
Too many password policies are outdated or downright nonsensical. Insisting on special characters or non-intuitive patterns is indeed a reason why people rotate their passwords or they change just one character. The result is that they end up using predictable patterns. Whereas a passphrase long enough would be more memorable and as secure. The longer it is, the harder it would be reverse it from a stolen hash. Ironically, many sites don't allow long passwords, like > 20 chars.
Which leads us to another question (that was not asked). Does it make sense to force people to change their passwords every 3 months or so (which is the main reason why that "password history" exists in the first place) ? If people were using unique passwords for each site, then there would be less worry about a password being compromised at one particular place. (A simple solutions exists: using a password manager).
To answer the question: that could be a possible security risk, depending on implementation. Storing plaintext passwords: red flag. Storing salted hashes: better. But what are they actually achieving in terms of security ? Very little I'm afraid.


How could malicious code changes in a GitHub pull request be masked by an attacker?

Bugs in the process of diff generation are unlikely.  Pretty much every web interface for a VCS system actually calls out to the VCS tool itself to generate the diffs.  Pretty much, any bug that might be there is pretty likely to be found and fixed quickly (it's generating user facing data, so any bugs there are high visibility).

Given that, your options amount to:

Homoglyph attacks, which you've already mentioned.  I don't see these as being very likely, as they are dependent on the font used for rendering, and they would have to be in data literals in most programming languages to not cause syntax errors, which in turn pretty severely limits what types of bug you can introduce.
Modification of binary files in the repo.  When dealing with binary data, most VCS systems only tell you the file changed, not how it changed, so there are no changes to review in the PR short of downloading and using the modified file.  This is one of the two reasons that sane people don't use version control for binary data, the other being that it's really bad at handling it efficiently.  Because not many people do this, it's not a likely attack vector.
Simple steganography.  This essentially relies on the reviewer not paying attention or not understanding the code they're reviewing.  The two obvious approaches are including a small change that introduces the bug in the middle of a couple of sections with lots of changes, or taking advantage of the fact that changes are shown per-line.


There are a couple of issues here.

First, MAC addresses, while intended to be unique, are in practice not. They are user-controllable.

The second issue is that your PHP-based application, if on the internet, will not be able to access the MAC address. The reason is that MAC addresses are layer 2 and layer 2 data is not typically sent across WAN links. If you want something to block, you have layer 7 data. This includes:

User agent
IP address
URL requested

However, if your application is on the internet, it is going to get attacked. The energy should be spent on ensuring the application follows good development practices. This includes keeping it updated with any frameworks and libraries it uses, output encoding user-supplied data, parameterized queries, and so on.


Microsoft email servers "require remote control of Android device security features"

Thankfully, you don't surrender remote admin capabilities to Microsoft.  However, you do surrender them to the e-mail system's administrator or some other IT admin there.

Generally this is kind of security done at a corporate level.  Corporations are as a whole concerned about loss of their intellectual property or privileged information (such as customer financial data or medical records).  As such, when they manage phones, they have to be able to remotely wipe a phone in the event of theft or loss to protect their reputation, their intellectual property, and their customers' privacy.

Is it safe?  Generally, although there are cases of admins getting something wrong and wiping the wrong phone.  Thankfully Android allows you to sync your data up to Google, so you generally don't lose anything, including purchases made through the application store.

I'm not a big fan of doing this for a university setting where you are a student.  You shouldn't have access to privileged or confidential data.  However, given the sex scandals that seem to crop up regularly, I suppose that they need to be able to wipe a phone where video of an assault is being distributed or stored.   For a university employee, OTOH, it makes perfect sense to me.

This is an enrollment in a Mobile Device Management solution as part of viewing email on the device.  Technically it's not being managed by the email servers.


Is it possible to execute a command on the local computer in meterpreter?

http://www.offensive-security.com/metasploit-unleashed/Meterpreter_Basics#execute

  The 'execute' command runs a command on the target

http://www.offensive-security.com/metasploit-unleashed/Meterpreter_Basics#shell

  The 'shell' command will present you with a standard shell on the
  target system.

If you want to run the command on the attacker host press Ctrl+Z to background the Meterpreter shell, and issue your command in the Metasploit shell. You can return to Meterpreter with the session command.


May HSTS block access to your site when you renew your SSL certificate?

HSTS only forces a site to use HTTPS. This prevents downgrade attacks such as SSLstrip from being effective. As HSTS says nothing about the certificate that will be used, it has no effect when you renew your certificate.
(Note that the certificate will still need to pass all standard validity checks.)

HTTP public key pinning, a related technology, is used to force a browser to only allow a site to be visited with a certificate using a specific public key. Note that this is different than specifying a full certificate. Even when HPKP is used, a new certificate can be installed on the server, provided that it uses the same private, public key pair.


Dealing with untrusted administrators in a Windows domain

The answer is simple: do not allow Domain Admins. Give access to specific functions to specific people who are in the job of administration. The "Domain Admin" group should be empty with alerts when a user is added to this group.

In small teams, this might be a little tricky, but you can include people outside of the IT admin staff for oversight, and you can create a scheme to make sure staff only gets a part of the privileges necessary to prevent tampering.

Give password management to a user who can only log into a single machine, and audit if other users log into that machine.
Allow log access to a person to someone who cannot change user accounts
This is the principle of "Least Privilege" at work, which is how you deal with any level of 'distrust'


You can use -S if you want to enable SSL


Can we prevent DDoS or spam form submission with client authentication?

tl/dr: Client authentication in the browser is useless because browser-based bots will automatically authenticate themselves, and
browser-less bots will get stopped by much simpler methods anyway.
This isn't really a surprise, because "client authentication" isn't
really effective for browsers (and is only slightly effective for other "kinds" of clients). Captcha, unfortunately, is the only real solution,
although it cannot protect you from targeted attacks.

Background
I want to clarify a detail from the comments.  My understanding is that the goal here isn't to require someone to login to use your form.  Rather, you want the client (in this case, the JavaScript app you build which runs in the user's browser) to authenticate with your server, so only people browsing your website can submit your form.  This authentication will happen by JavaScript adding an authorization token to the request, and the server rejects any form submissions that don't contain the correct authorization token.
Before I go into details I want to emphasize one important point: it is not possible to restrict someone to only using your "app".  Your JavaScript runs on their computer, in their browser.  As a result an attacker can easily reverse-engineer your app (which is extremely easy when it is javascript in a browser), determine how it authenticates itself with the server, and then reproduce that in anyway necessary.  To try to limit users to only using your app effectively means that you are trying to implement DRM, and it is simply not possible (especially in cases like this).  You can make things harder for attackers, but you can't stop them outright.  Still, let's discuss your question in more specifics.
Bots
In order to protect against spam bots, you first have to understand how they work.  There are of course a ridiculous number of varieties, but I'll focus on two general "types" (keep in mind that I've chosen these categories somewhat arbitrarily):

Many simple bots request pages from the website using a non-browser HTTP client (for simplicity, imagine they use curl).  They then  parse the HTML looking for forms.  If they find one they also look at the inputs on the form, decide on how to "fill out" the inputs, build an HTTP request with their data, and then send it off to the url of the action property on the form.  Pretty simple.  They will also fake details in the request headers (Origin, User-Agent, etc...) to look more like a regular user.
However there are "fancier" bots out there that actually use browsers.  You can build your own bot using something like selenium which effectively lets you automate browsing the web using an actual browser.  The bot uses Selenium to load up a page in the browser, click on input forms, send in keyboard input, and then click on the submit button.

Protecting against "simple" bots
The simple class of bots reads the HTML returned by the server to figure out what kind of request the server is looking for, builds a matching request, and sends it to the server.  If your client-authentication process involves using JavaScript to attach additional credentials to the request, then that authentication process will actually stop such bots from executing successfully.
However, it isn't technically the presence of the authentication that keeps the bots out - it is simply the use of JavaScript that stops them, because the bot doesn't know anything about steps that JavaScript takes.  For this class of bots, you could just as easily have JavaScript intercept the form submission, add some predetermined data to the request (imagine it adds something like not_a_bot=true to the request data), and submit it with Ajax.  The server then rejects any requests that don't include that not_a_bot=true flag.  This sort of incredibly simple check will stop bots that don't execute your JavaScript. In fact, I've actually used this in production systems and it dramatically cuts down on bot submissions.  The only downside is that it also locks out users that don't have JavaScript enabled (which your proposed client authentication method also does).
So, will your authentication step help? Yes!  However, only by accident, and there are much simpler ways to accomplish the same thing.
Protecting against "fancier" bots
However some bots work by using an actual browser, which means it runs any JavaScript passed down by the server.  As a result any sort of automatic authentication step that is executed by your JavaScript will automatically happen for these kinds of bots as well.  In fact, it is nearly impossible to differentiate between these bots and regular users.
This means that whether you secure your form by adding the not_a_bot=true flag in JavaScript, or whether you secure it by having JavaScript add in an authorization token to the request, these bots will take the same exact steps and the server will accept the spam submission.  The attacker won't even have to reverse engineer your app - your own JavaScript will allow the spam bot to circumvent your protections.
How do you stop these bots from filling out your forms?  There's only one cost-effective solution: a captcha system (although even that isn't a guarantee).
DDoS
DDoS is not even worth a mention.  A DDoS attack works by simply flooding the server with so much traffic that it cannot keep up.  While there are some kinds of DDoS attacks that might be prevented by trying to ignore submissions from bots, the most common kind won't be.  Many DDoS attacks work by simply sending so much network traffic to your infrastructure that there is not enough bandwidth to keep up.  When that happens there is nothing that can be done at the server level to stop the DDoS attack.  Completely different strategies (mainly at the network-level) are required there.  Whoever suggested that this might help against a DDoS simply doesn't understand how such attacks work.
Summary
So after breaking things down we can see that client authentication provides absolutely no benefit.  It would stop simple spam bots, but only because it requires JavaScript which simple bots don't execute.  Instead there are much simpler steps which would stop these kinds of spam bots anyway.  Moreover, the client authentication will provide no protection against bots that use actual browsers to do their job.  Nothing will stop those, although a good captcha may at least discourage drive-by-bots that aren't specifically targeting you.


Is it true that certificates requested with a specific CSR can only be used on the machine where the CSR was generated?

No, it is not true.

The CSR defines various parameters for the certificate that you are requesting, such as the Common Name, any Alternative Names, etc. However the CSR is, ultimately, just a file, and you can do all the usual file things with it -- such as copying or moving it to another server, if you wanted to.

Not that even that much is required. Your SSL certificate that you receive in response to your CSR (oftentimes with a key file and/or a "certificate chain") is all that you need. And you can put it on as many machines as you want, even if none of them ever saw the CSR in the first place, let alone were the originating machines for it.

Case in point: I manage a cluster of 5 (soon-to-be-deprecated) email servers, another cluster of 9 (soon-to-replace-the-former) email servers, a pair of BigIp load balancers, a cluster of 5 web servers, and more -- and all 20+ of them use exactly the same certificate, key, and chain files, but not the CSR (heck, the load balancers don't even have an option in their GUI to upload the CSR at all!). The CSR that was used to get this certificate in the first place? The machine that generated it was decommissioned a while ago, taking the sole copy of the CSR with it.

What you can't do, however (well, not without provoking errors anyway) is use your certificate on a domain other than that named on the certificate; e.g. if you have a certificate for example.com, with an alternative name of example.net, you could not use it on example.org. (Well, technically you could, but you'd get "invalid certificate" errors any time you visited it.) You also could not use it on sub.example.com. This has nothing to do with the CSR other than that's where you put those names in the first place, though.


Should I only let my TV connect to the guest WiFi?

Using a guest WiFi for IoT devices is essentially just a practical, easy to understand implementation for network segmentation. The goal is to prevent lateral movement between and from IoT devices. As a typical user isn't aware of such terminology and how this should be implemented, this might actually be a good tip.
However, in order to increase security, using this recommendation has some prerequisites:

The home router must have a guest network feature, obviously, but not every router has it.
The guest network must be isolated from the home network.
Ideally, all devices on the guest network should be isolated from each other, too.

Ziv Chang (Trend Micro): Inside the Smart Home: IoT Device Threats and Attack Scenarios sums up some typical security measures for IoT devices, the network segmentation among them:

Map all connected devices. All devices connected to the network, whether at home or at the enterprise level, should be well accounted
for. Their settings, credentials, firmware versions, and recent
patches should be noted. This step can help assess which security
measures the users should take and pinpoint which devices may have to
be replaced or updated.
Change default passwords and settings. Make sure that the settings used by each device are aligned toward stronger security, and change
the settings if this is not the case. Change default and weak
passwords to avoid attacks like brute force and unwanted access.
Patch vulnerabilities. Patching may be a challenging task, especially for enterprises. But it is integral to apply patches as
soon as they are released. For some users, patches may disrupt their
regular processes, for which virtual patching could be an option.
Apply network segmentation. Use network segmentation to prevent the spread of attacks, and isolate possibly problematic devices that
cannot be immediately taken offline.


UPnP can safely be disabled. If a service needs a port punched it’ll tell you.

In regards to MITM and altered firmwares: it’s a Wild West our there. Some manufacturers have secure signed images severed on secure servers, some just flash whatever random binary they find over HTTP. You really won’t be MITM’d be your ISP hopefully so that’s not an issue however these unsigned and insecure firmware devices can be compromised from an adjacent compromised device. So if you’re already breached you may be in for an even bigger headache where your only real option is likely to bin the device. If the device is your fridge I’m sorry.

This same principle also applies to all outgoing connections as well if there is some vulnerability in how it handles the responding data. If either the server is compromised or an adjacent device is compromised then an insecure and vulnerable device could be hijacked.

What’s your best bet? Probably keeping them from accessing the wider internet. When that’s not possible, use client isolation so that hijacked devices can’t infect your other devices. Really your best bet is to use as few IOT devices since you really have very little control or access to the configuration.


KARMA attack does not require for an attacker to be in range of the target network?

Target has connected to some AP before
The KARMA attack requires that you have connected to some AP before, not necessarily the rogue AP.
Many wifi devices broadcast the SSIDs of known access points because, among other reasons, it allows faster [re]connecting and thus better user experience. So if you have connected to VerySecureWorkWifi earlier and have set your device to automatically reconnect to it, then your device (if it's vulnerable to KARMA) will be repeatedly broadcasting that to the world.
So any attacker can listen to that broadcast, and respond with "Yes, what a lucky coincidence! Now my SSID is VerySecureWorkWifi, please connect!".


Securely sending packets without them being spoofed

Have you heard about JWT or stateless sessions?
This sounds like a job for an encrypted packet that gets sent to the client, and sent back, for the next packet to be sent. This JSON Web Token could be used to signify who talks to your server by containing the information it needs in an encrypted format to make sure things are secure and compliant. This is best done over an encrypted connection.
An example
Andy and Deli are playing a game. Andy gets a JWT with his information, and Deli gets a JWT with his information.
Some of the information in the JWT is the same(game id, game meta data, so forth) and some of it is unique(player unique id, player ip, something else unique to the player).
When Andy communicates, he JWT is sent along with his packets, and verifies his unique information. Once that is verified his move is then done, and forwarded. It then gets some ALTERED unique information(like updating the time of last move by this player) and gets sent back to him, and the move gets sent to everyone else.
Now Deli wants to cheat. He instead puts Andy's Unique id into his move and sends it to make it look like Andy did a new move into a bad place.
The JWT is decoded, and it's seen that Deli is cheating, so Deli gets kicked, and Andy wins by default since Deli sent a command for a user that isn't Deli.
A Rose by any other name
Often you'll see these also referred to as Cookie Sessions, Stateless Sessions, JSON Web Tokens, and a myriad of other names, but they all have the same idea(and when sent over TCP, usually are in the cookies)
What is a Stateless Session?
A stateless session is a session that lives and dies with it's token.
Usually they are encrypted on the server end with a server secret that is related to whatever is happening. These tokens don't live in databases, don't reflect any sort of long term storage, and expire eventually.
To keep them secure they are usually encrypted with a strong cipher suite, and a secret of some sort that gets decrypted on the fly, modified, and then re-encrypted. This information is usually a JSON document containing meta information that doesn't get modified often(if at all) that can be sent back and forth and since it's encrypted it means that any modification makes it null and void.
Any modifications to these render them as new sessions, and any data in them is lost. This means that if you do your checks and balances correctly you can even use it as a full session for a user on most websites.


Sensitive information rendered into inline static javascript object vulnerability if user saves HTML page

I was able to render the javascript object in a separate html file, name it as .js file, and include it as a script in the html. Problem solved.

Yes I could have switched to Ajax but I had worked a lot to parse the information with the template engine already and there was a lot of stuff to send.


How to import plain public key into java keystore?

The standard (or at least conventional) certificate request process does require the privatekey matching the publickey to be certified. The pre-packaged operations of Java's keytool utility and the openssl commandline are limited to this standard process, as are several other existing Qs.

However, it is not fundamentally necessary. As long as you have a privatekey for the certificate issuer, nominally a Certificate Authority, and a certificate for that CA key or at least some critical metadata normally embedded in such a certificate, it is possible to issue a child cert for a given child publickey.

This can be done with OpenSSL by calling the X509_* routines in libcrypto from custom code; in Java the classes used by standard keytool are not officially part of the JRE spec but are open source, but if you can use the BouncyCastle third-party libraries (bcprov + bcpkix) they directly expose the needed functions in a convenient and documented/guaranteed form, so I show that. This creates a very minimal certificate with little of the information and especially none of the extensions that are commonly present in real, CA-issued certificates. If this is not sufficient for your needs, ask a more complete question.

For simplicity I read the (subject) pubkey PEM from a named file, and the CA key and cert from a JKS in a named file at a named alias. These sources of information can be replaced by others as you wish. I also don't do any error handling leaving Java to do its default stacktrace; you may need better.

import java.security.*;
import java.security.cert.X509Certificate;
import java.security.interfaces.RSAPrivateKey;
import java.util.Date;
import org.bouncycastle.asn1.x500.X500Name;
import org.bouncycastle.asn1.x509.SubjectPublicKeyInfo;
import org.bouncycastle.cert.X509v3CertificateBuilder;
import org.bouncycastle.openssl.PEMParser;
import org.bouncycastle.openssl.jcajce.JcaPEMWriter;
import org.bouncycastle.operator.ContentSigner;
import org.bouncycastle.operator.jcajce.JcaContentSignerBuilder;

static void Se179526FakeCert (String[] args) throws Exception {
    // pubkey.pem cakey.jks pw alias
    Object spki  = new PEMParser (new FileReader (args[0])).readObject();
    KeyStore ks = KeyStore.getInstance("JKS");
    ks.load (new FileInputStream (args[1]), args[2].toCharArray());
    PrivateKey cakey = (PrivateKey) ks.getKey (args[3], args[2].toCharArray());
    X509Certificate cacert = (X509Certificate) ks.getCertificate (args[3]);
    Date now = new Date(), exp = new Date(now.getTime()+30*86400*1000); // 30 days validity

    ContentSigner signer = new JcaContentSignerBuilder ("SHA256with"+cakey.getAlgorithm()).build(cakey);
    byte[] enc = new X509v3CertificateBuilder(
            /*issuer*/new X500Name (cacert.getIssuerX500Principal().getName()), /*serial*/BigInteger.valueOf(now.getTime()),
            /*validity*/now, exp, /*subject*/new X500Name ("CN=dummy"), /*spki*/(SubjectPublicKeyInfo) spki
        ) .build(signer) .getEncoded();
    // .addExtension's if&as needed before .build
    Certificate cert = CertificateFactory.getInstance ("X.509") .generateCertificate(new ByteArrayInputStream(enc));
    // could now store in a keystore; or to write out in PEM:
    JcaPEMWriter out = new JcaPEMWriter (new OutputStreamWriter (System.out));
    out.writeObject (cert); out.flush();
}


Storage of SSL private key in load balancer VS HSM

From the security point of view, keeping the private key inside HSM is an ultimate solution. However, HSM has a throughput limitation, which brings a question of what rate of handshake requests do you expect to your web service and is it guaranteed to be lower than the max number that HSM can process.

If storing private keys in the HSM is not an option, then I still wouldn't store them in plain text. Every cloud solution offers tools for keys management, for example, if your service where run AWS - AWS Key Management Service (AWS KMS). Azure and gcloud will have their own tools.


Answer from @SteffenUllrich

This is exactly the same as option 1 only with a different webroot and
thus it provides the same security.