Can going to a bad website on firefox, or installing a malcious firefox plugin, infect other parts of my home folder on a Linux system?

The short answer is: if your Firefox is compromised, it can do whatever it wants. It can modify whatever files it wants. It can even keylog and get root. But there are a few ways you can improve your security, like using a more secure browser, AppArmor or the NoScript plugin. The long answer is...

Yes, if your Firefox process is compromised, it can do absolutely anything your regular user can do. In Linux, security comes from separation of users. I talked a little about the risks of assuming you have intra-user protection here. Basically, your system has security checks all over, and if two process' are of the same user, then they are considered to be equally trusted, and can interfere with each other at will. This includes keylogging, which means they can sniff your root password next time you type it in. Or it could inject keystrokes, move the mouse, modify all files in your home directory and many files outside of it. It could access the network at will, and pretty much everything else. If your Firefox process is compromised, you have much more to worry about than your Chromium folder being modified. Firefox runs as your user. Your user is you. Malware that breaks out of Firefox inherits that privilege, and will be able to do whatever you can do, such as the few examples I gave above.

Also note that Chromium is significantly more secure than Firefox. While Firefox has no proactive security mechanisms whatsoever, Chromium has them in abundance (suid chroot sandbox, seccomp-bpf sandbox, several types of namespace sandboxes, and more). In many contents, Firefox is almost always the first to be hacked, with Chrome/Chromium surviving the longest, and taking the longest for world-expert hackers to find ways through all the sandbox layers. If your primary goal is security, you might want to stick with using just Chromium.

If you still want to use Firefox though, you get mitigate this to a large extent by using a sandbox that comes with Linux. Ubuntu has the AppArmor sandbox, so you can use it to protect your browsers, among other things. I don't know how up to date it is, but the instructions for enabling it can be found here. AppArmor is a type of sandbox called a MAC, or Mandatory Access Control, which is controlled by the kernel, the core and boss of the operating system which runs with even more privileges than root. When an AppArmor profile is enabled, it tells the kernel to restrict what folders and files a process is allowed to access. The AppArmor profile for Firefox is written to give it only the permissions it needs, and nothing else. If it tries to access anything it's not allowed to, the kernel will promptly deny access.

Here is the default Firefox AppArmor policy for Ubuntu 14.04, which you can look at to get an idea of how it works. As you can see, it allows read access to most folders, but only allows writing to configuration folders related to Firefox. Chromium folders are not in the whitelisted paths, and any attempts to write there would be denied.

# vim:syntax=apparmor
# Author: Jamie Strandboge <jamie@canonical.com>

# Declare an apparmor variable to help with overrides
@{MOZ_LIBDIR}=/usr/lib/firefox

#include <tunables/global>

# We want to confine the binaries that match:
#  /usr/lib/firefox/firefox
#  /usr/lib/firefox/firefox
# but not:
#  /usr/lib/firefox/firefox.sh
/usr/lib/firefox/firefox{,*[^s][^h]} {
  #include <abstractions/audio>
  #include <abstractions/cups-client>
  # TODO: finetune this for required accesses
  #include <abstractions/dbus>
  #include <abstractions/dbus-accessibility>
  #include <abstractions/dbus-session>
  #include <abstractions/gnome>
  #include <abstractions/ibus>
  #include <abstractions/nameservice>
  #include <abstractions/p11-kit>

  # Addons
  #include <abstractions/ubuntu-browsers.d/firefox>

  # for networking
  network inet stream,
  network inet6 stream,
  @{PROC}/[0-9]*/net/if_inet6 r,
  @{PROC}/[0-9]*/net/ipv6_route r,
  @{PROC}/[0-9]*/net/dev r,
  @{PROC}/[0-9]*/net/wireless r,

  # should maybe be in abstractions
  /etc/ r,
  /etc/mime.types r,
  /etc/mailcap r,
  /etc/xdg/*buntu/applications/defaults.list    r, # for all derivatives
  /etc/xfce4/defaults.list r,
  /usr/share/xubuntu/applications/defaults.list r,
  owner @{HOME}/.local/share/applications/defaults.list r,
  owner @{HOME}/.local/share/applications/mimeapps.list r,
  owner @{HOME}/.local/share/applications/mimeinfo.cache r,
  owner /tmp/** m,
  owner /var/tmp/** m,
  /tmp/.X[0-9]*-lock r,
  /etc/udev/udev.conf r,
  # Doesn't seem to be required, but noisy. Maybe allow 'r' for 'b*' if needed.
  # Possibly move to an abstraction if anything else needs it.
  deny /run/udev/data/** r,

  /etc/timezone r,
  /etc/wildmidi/wildmidi.cfg r,

  # firefox specific
  /etc/firefox*/ r,
  /etc/firefox*/** r,
  /etc/xul-ext/** r,
  /etc/xulrunner-2.0*/ r,
  /etc/xulrunner-2.0*/** r,
  /etc/gre.d/ r,
  /etc/gre.d/* r,

  # noisy
  deny @{MOZ_LIBDIR}/** w,
  deny /usr/lib/firefox-addons/** w,
  deny /usr/lib/xulrunner-addons/** w,
  deny /usr/lib/xulrunner-*/components/*.tmp w,
  deny /.suspended r,
  deny /boot/initrd.img* r,
  deny /boot/vmlinuz* r,
  deny /var/cache/fontconfig/ w,
  deny @{HOME}/.local/share/recently-used.xbel r,

  # TODO: investigate
  deny /usr/bin/gconftool-2 x,

  # These are needed when a new user starts firefox and firefox.sh is used
  @{MOZ_LIBDIR}/** ixr,
  /usr/bin/basename ixr,
  /usr/bin/dirname ixr,
  /usr/bin/pwd ixr,
  /sbin/killall5 ixr,
  /bin/which ixr,
  /usr/bin/tr ixr,
  @{PROC}/ r,
  @{PROC}/[0-9]*/cmdline r,
  @{PROC}/[0-9]*/mountinfo r,
  @{PROC}/[0-9]*/stat r,
  owner @{PROC}/[0-9]*/task/[0-9]*/stat r,
  @{PROC}/[0-9]*/status r,
  @{PROC}/filesystems r,
  /sys/devices/pci[0-9]*/**/uevent r,
  owner @{HOME}/.thumbnails/*/*.png r,

  /etc/mtab r,
  /etc/fstab r,

  # Needed for the crash reporter
  owner @{PROC}/[0-9]*/environ r,
  owner @{PROC}/[0-9]*/auxv r,
  /etc/lsb-release r,
  /usr/bin/expr ix,
  /sys/devices/system/cpu/ r,
  /sys/devices/system/cpu/** r,

  # about:memory
  owner @{PROC}/[0-9]*/statm r,
  owner @{PROC}/[0-9]*/smaps r,

  # Needed for container to work in xul builds
  /usr/lib/xulrunner-*/plugin-container ixr,

  # allow access to documentation and other files the user may want to look
  # at in /usr and /opt
  /usr/ r,
  /usr/** r,
  /opt/ r,
  /opt/** r,

  # so browsing directories works
  / r,
  /**/ r,

  # Default profile allows downloads to ~/Downloads and uploads from ~/Public
  owner @{HOME}/ r,
  owner @{HOME}/Public/ r,
  owner @{HOME}/Public/* r,
  owner @{HOME}/Downloads/ r,
  owner @{HOME}/Downloads/* rw,

  # per-user firefox configuration
  owner @{HOME}/.{firefox,mozilla}/ rw,
  owner @{HOME}/.{firefox,mozilla}/** rw,
  owner @{HOME}/.{firefox,mozilla}/**/*.{db,parentlock,sqlite}* k,
  owner @{HOME}/.{firefox,mozilla}/plugins/** rm,
  owner @{HOME}/.{firefox,mozilla}/**/plugins/** rm,
  owner @{HOME}/.gnome2/firefox*-bin-* rw,
  owner @{HOME}/.cache/mozilla/{,firefox/} rw,
  owner @{HOME}/.cache/mozilla/firefox/** rw,
  owner @{HOME}/.cache/mozilla/firefox/**/*.sqlite k,

  #
  # Extensions
  # /usr/share/.../extensions/... is already covered by '/usr/** r', above.
  # Allow 'x' for downloaded extensions, but inherit policy for safety
  owner @{HOME}/.mozilla/**/extensions/** mixr,

  deny @{MOZ_LIBDIR}/update.test w,
  deny /usr/lib/mozilla/extensions/**/ w,
  deny /usr/lib/xulrunner-addons/extensions/**/ w,
  deny /usr/share/mozilla/extensions/**/ w,
  deny /usr/share/mozilla/ w,

  # Miscellaneous (to be abstracted)
  # Ideally these would use a child profile. They are all ELF executables
  # so running with 'Ux', while not ideal, is ok because we will at least
  # benefit from glibc's secure execute.
  /usr/bin/mkfifo Uxr,  # investigate
  /bin/ps Uxr,
  /bin/uname Uxr,

  # Site-specific additions and overrides. See local/README for details.
  #include <local/usr.bin.firefox>
}

Another way to mitigate this is by using NoScript. It allows you to block dangerous JavaScript, Flash, etc from websites, which makes attacks on Firefox much less likely to succeed. Even if you keep most scripts enabled because disabling scripts causes many websites to not work as expected, the plugin still provides transparent protection from other threats, such as clickjacking and XSS. It's a very popular plugin and very well regarded in the security community. I highly recommend you install it, in addition to enabling AppArmor, if your goal is to minimize the risk of a malicious website compromising your computer or any files on it.


Are there any tools/methods to probe a web app from diffferent IPs?

I have read the book, and I also have a good example of a web app blocking traffic from certain IPs ..

You can spoof your source IP address the way you want but you won't get any response because once the forged TCP/UDP packet reaches your target (assuming it makes it through firewalls) the reply will be sent to that FORGED IP address and it will never reach you.

You will have better results using TOR as you mentioned!


Man-in-the-middle attack (ACME / Let's Encrypt) on Authorization Key?

From https://letsencrypt.org/how-it-works/:

Let’s Encrypt identifies the server administrator by public key. The first time the agent software interacts with Let’s Encrypt, it generates a new key pair...

Although it doesn't say it explicitly, the server admin must send the public key to Let's Encrypt at this point (otherwise, it's impossible to see how the later digital signature verification would work).  So, this is the public key that Let's Encrypt would use to verify the digital signature on the nonce.  Therefore, in your scenario, if a rogue actor were to create his own keypair and use his private key to sign the nonce, the signature verification would fail because the public key that Let's Encrypt would use to verify the signature would not correspond with the private key used to create the signature.


Firefox not deleting HTTP Basic authentication credentials although being instructed to do so

Firefox (Firefox 68.0, under Linux) doesn't store this info in Cookies and Site Data but in History.

You need to go to Preferences->Privacy & Security and under the History section, click on Clear History.... Make sure the Active Logins checkbox is checked before you submit.


Which of the fields represents the digital signature value of the CA in a certificate?

The name of the field is Certificate Signature Value.

For example, this site SSL certificate for : ssl333133.cloudflaressl.com has the value :

Size: 72 Bytes / 576 Bits
30 46 02 21 00 b7 76 6a 60 32 00 4b 76 49 92 8f
cb 1a b5 d7 64 55 37 fb 81 0c 65 23 1e 80 b5 a1
e5 1b 7a 7c 5e 02 21 00 a5 22 6e 4e fe 3a b4 4e
15 72 e1 d9 48 c8 b5 4a 3e 63 5f c4 d5 34 e7 e6
6e 87 55 89 8c 28 11 cf


Based on your reference the SSL/TLS keys you refer to are the pre-master keys which can be used to decrypt a packet capture of the connection. Because of this use case they are only relevant for specific development and debugging. Therefore (and for security reasons) they are only available if you start the browser using a specific environment variable. And because the keys are binary and the tools you use to decrypt the traffic expect the keys in a file anyway it makes no sense to offer a GUI to show these keys.

Note that you don't need a debug mode of the browser to get these information. See Decrypting TLS Browser Traffic With Wireshark – The Easy Way!.


PCI-DSS scope: Using P2PE Compliant devices

I'd suggest putting in a logic control (rather than just the current physical tamper control) to verify no clear text cardholder data is ever received by the connected system environment. If such data is identified, it should raise an alert.
Verify the hashing mechanism in use is strong (e.g. SHA2) and uses salts so you're not vulnerable to rainbow table attacks.

You still need to document how cardholder data is protected within the environment but the connected system should be removed from scope in the same way as a system handling truncated data would be, or a system handling encrypted data would be where the entity has no access to the keys which would be used for decryption.


If you connect such domain the certificate is checked by your browser. The certificate of the HTTPS server must be signed with one of certificate of certification authority your computer trusts. If it is not signed by it you will see warning from your browser the connection can't be trusted.

If ISP will be able to manage the certificate is signed by one of these certification authorities (or add another certification authority to your trusted certification authorities) you will not be able to notice it until you know, what CA issued the correct certificate for the server and you will check it manually in the browser.

This will never happen under "normal" conditions as public certification authorities will never issue certificate to anybody else than the server (domian) owner. And in order the ISP is able to install another certificate to your trusted CA store they have to somehow hack your PC or provide you a malicious code in some way (i.e. they give you a CD with some "drivers"). But its not that easy as it seems and I would say no ISP will risk something like this.

Edit:
I forgot to mention that is server will use insecure protocol (i.e. SSLv2) with insecure encryption suite there is also possibility the MITM can happen.


Does Windows 10's telemetry include sending *.doc files if Word crashed?

Here is what they spy on, finally officially admitted after being proved again and again by different independent sources. That should make a pretty good idea on what actually is transmitted.

To actually see what's being reported you can give yourself permissions for
%ProgramData%\Microsoft\Diagnosis directory and look what's in there, but the file are encrypted which is a very suspicious thing.

What you can look at in the newer version is the Diagnostic Data Viewer. But that does NOT guarantee or prove that there is documents privacy in any way.

At this point my guess is that they will transmit parts of files that generated crashes, or if they consider proper to do so and definitely can transmit any type of document via the encrypted content in \Diagnosis and https as the transmission way.

Their EULA states:

  Finally, we will access, disclose and preserve personal data,
  including your content (such as the content of your emails, other
  private communications or files in private folders), when we have a
  good faith belief that doing so is necessary to: comply with
  applicable law or respond to valid legal process, including from law
  enforcement or other government agencies;
  2. protect our customers, for example to prevent spam or attempts to defraud users of the services, or to help prevent the loss of life or
  serious injury of anyone; 3. operate and maintain the security of our
  services, including to prevent or stop an attack on our computer
  systems or networks; or
  4. protect the rights or property of Microsoft, including enforcing the terms governing the use of the services - however, if we receive
  information indicating that someone is using our services to traffic
  in stolen intellectual or physical property of Microsoft, we will not
  inspect a customer's private content ourselves, but we may refer the
  matter to law enforcement.

Conclusion: they can and will do it at will.


This is a relic of the original Internet addressing scheme, now retronymed 'classful' and obsolete almost 3 decades. See e.g. https://stackoverflow.com/questions/29285954/wsastringtoaddress-thinks-1-2-3-is-a-valid-ip-address or more officially http://pubs.opengroup.org/onlinepubs/009695399/functions/inet_addr.html . Note that 0.0.0.0 itself, in whatever representation, cannot actually be a host address, but since it is the reserved special value INADDR_ANY some software replaces it with another address like 127.0.0.1 which is routable, or close enough. OTOH you can't get a valid certificate for HTTPS/SSL/TLS for either 0.0.0.0 or 127.0.0.1 from any 'real' CA (more specifically, any CA subject to CABforum rules or trusted by any major browser).

Although this is primarily a programming-for-networking issue, there is a slight security impact in that nowadays 99.99% of systems on the Internet are operated by individuals (cf. Dilbert) with sub-fractional clues how the Internet actually works, so that phishers, scammers, etc. sometimes use these obsolete address formats (especially the single number) in URLs and email addresses to confuse, mislead, and deceive such people.


Should a webserver's access to certain directories be limited?

Nginx should indeed have access blocked to arbitrary locations on your filesystem. In short, if it doesn't need access, don't give it any, because that limits the damage it could do. This applies to both read and write, and can be done by running nginx as its own user (probably the default on your system), not adding that user to common groups, and being restrictive about your filesystem permissions on the rest of the system (i.e. don't use 777 just because you're having troubles getting the right permission set). You may also wish to look into SELinux for more advanced controls.

The warning you have there is an extension of that idea. Outside users don't need to be able to read your nginx config, but the nginx user does. These files should never be located in one of your document roots, but nonetheless you should have nginx rules that block any requests to them (the specifics of the rules is off-topic for here, but would fit well on Server Fault).


How to respond when network info sec check requires run of downloaded unknown .exe?

Run it in a virtual machine. Either they are too dumb to be serious about it, or they're just setting you up, but this way you'll definitely pass the test.

In case you won't get the access from your host machine that way, try to set up bridging (see: VirtualBox; VMWare) for that virtual machine and then route the traffic of the host machine through NAT in the VM. This will help in case the executable is checking and reporting the MAC address of the machine it's being run on. Again, either this is your actual assignment or they have dealt with sane people before. Don't give up, you'll learn something anyway.

Also, in (an unlikely) case the university is really good and the event in question has anything to do with Meltdown/Spectre, it might be a good idea to carefully migrate the said virtual machine away from your personal computer towards some cheap cloud out there soon after you've run that executable (and well before you've opened an university-owned Web page, just in case).


What is the responsible thing to do when I care about a vulnerability more than the team behind the system?

There is a couple of things you can do.

1) Do nothing

2) Tell the world

I would go with 1) - Reason for this is, you can get into serious trouble if you tell the world (Depending on what laws you have broken to get the knowledge, and you probably have broken some laws even if you think you have not), and still could just by telling the company, I have and a lot of others have too.

Simply not worth it most of the time.


You are out of luck.  A passphrase protected encrypted private key means you have to guess it and with the high entropy of a typical passphrase it will be very difficult.  Granted if you have a rough idea of what the passphrase is, you can write a script to try to brute force it (e.g., it was something like 'correct battery horse __' and subject to a dictionary attack).

This is the whole reason you put the passphrase on the private key.  (Granted I usually remove the passphrase from my SSL private keys on my server for convenience restarting apache/nginx; though leave them only root readable; figure if someone got to root they can install a keylogger and grab my passphrase anyhow).

EDIT: I should add in principle you could get at your private key if you break RSA (solve the problem of factoring the modulus N the product of two ~1024 bit prime numbers that's in the unencrypted public key; which would let you quickly regenerate the private key) or the passphrase encryption mechanism (typically DES3) to recover the private key.  However, if you could do either then anyone else could as well, which would not be a good situation.  Also, unless you have made fundamental breakthroughs in number theory, computer science, or developed a quantum computer it is prohibitively expensive to brute-force break RSA (like a million computers going for a million years would have under a 0.02% chance of breaking a 2048-bit RSA key).


You can know whether a file has been modified by checking a secure hash of it's contents. You can do this manually, or you can use your package manager; with RPM it's rpm -V, with apt you use debsums.

Then it's a matter of checking to see if the process was started using that file. That bit's simple as well: check the proc entry. This keeps track not only of the path to the file, but also its inode number, so if the file is replaced, it will not match. Observe:

[tylerl@tyler-11 ~]$ ./foo &
[1] 26157
[tylerl@tyler-11 ~]$ ls -l /proc/26157/exe
lrwxrwxrwx 1 tylerl tylerl 0 2013-01-16 12:31 /proc/26157/exe -> /home/tylerl/foo
[tylerl@tyler-11 ~]$ ls -l /home/tylerl/foo
-rwxr-xr-x 1 tylerl tylerl 8.3K 2013-01-16 12:31 /home/tylerl/foo
[tylerl@tyler-11 ~]$ echo 1 >> foo
-bash: foo: Text file busy
[tylerl@tyler-11 ~]$ rm foo
rm: remove regular file `foo'? y
[tylerl@tyler-11 ~]$ echo 1 > foo
[tylerl@tyler-11 ~]$ ls -l /proc/26157/exe
lrwxrwxrwx 1 tylerl tylerl 0 2013-01-16 12:31 /proc/26157/exe -> /home/tylerl/foo (deleted)
[tylerl@tyler-11 ~]$ ls -l /home/tylerl/foo
-rw-r--r-- 1 tylerl tylerl 2 2013-01-16 12:32 /home/tylerl/foo

Note two things: (a) the file can't be modified while it's running, and (b) while you can delete it and replace it, the new directory entry will correspond to a different executable, and the proc entry will say (deleted) to warn you of the difference.

Note that I could recover the original file just by running cp /proc/26157/exe ./orig_exe, and then I could examine it as necessary. Files aren't actually deleted from disk until the last reference is closed.


Are there any functional differences in the implementations of OpenSSL, GnuTLS, Java's TLS, and .NET's TLS?

There is a lot of variability in SSL/TLS; for instance, when data must be sent, it is split over one or several records, and the implementation is free to choose the size of each record as it sees fit (within the standard size constraints). Modern implementations, in particular, tend to make a few very short records (with 0 or 1 byte of application data) as a protection against the BEAST attack. Also, every implementation supports only a subset of the hundreds of possible cipher suites. The bottom-line is that it is possible to distinguish implementations from each other (I do not know of a readily available tool which does that, but it does not look very hard to do).

Leaking which implementation is used is not a big issue by itself (although it tends to make people nervous). Anyway, if the SSL server is used within a Web server, identifying the Web server already yields definite clues about the SSL implementation (if the server is IIS, the SSL code will be the one from Microsoft...). Also, there are not so many SSL/TLS implementations out there; the attacker needs not guess which is used, he just has to try out all the exploits he knows until one works.

If you use an implementation which has "questionable features", then the issue is not that the attacker may know or guess that you use this implementation -- the issue is that you use an implementation with questionable features.


Can a rogue client bypass the Wi-Fi Access Point?

Can't comment yet, but I'd say it really depends on what filtering/security measures you're activating, and when you're doing it.

Getting the WiFi key, one a user as been infected is pretty easy. I would go for some ARP Broadcast to detect every other terminals and try to monitor their activities and perhaps detect some vulnerabilities, and scan the open ports on the router.

The most viable solution would be to simply block the MAC Adress of the rogue device on the WiFi or router but if it has detected other devices and perhaps open ports, it still could access it from outside the local network.


Taking a look at git signing process, it says that only commit information can be source verified by this method. After version 1.8.3, git can also sign commits and merge requests.

The person who execute those operations provides the gpg key password for signing, and everyone that looks at the commit, tag and merge can see if it comes from a "trusted source" by checking the public part of the gpg key.

However, this solution does not encrypt individual files. It's just for checking that commits are actually from a trusted source. What could help you is to "enforce" commit hooks usin eID on your relative's document repository.

tl,dr: Git does not encrypt individual files so, it will not be a viable solution to you


Endpoint security refers to the security controls of laptops or desktops to apply below controls:

Detect malicious activity
Application controls: example; Block malicious applications from running user from running
Privilege management: Remove local admin rights from users, Elevate privilege on-demand for authorized applications
Credentials theft protection: example Contain attacker to the endpoint limit lateral movement
Anti virus: run periodic scans on machines
Apply the latest Patches to OS and applications
Collect user logs

Some endpoint detection tools provide centralized management tool which allows the admin to monitor and manage all the users in one place.

A few examples on Endpoint security tool provider are: Forcepoint, Cyberark, Kaspersky


Hypothetical Scenario: How will an Ubuntu computer fare?

Whilst obviously its impossible to state definitively without knowing the capabilities of the specific nation state attacker in question, I'd be betting on Alice every time here.

There are a load of ways that a nation state attacker could attack this kind of setup.  The obvious approach with physical access to the network in advance would be to take control of the default gateway router/firewall and ensure that it's possible to intecept all of bob's Internet bound traffic.

Then :-

a) Possess a trusted root CA certificate and use it to MITM all SSL encrypted traffic including browsing.  It seems very likely that high-end nation state attackers have either copies of root CA keys which are trusted in browsers used by Ubuntu, or have an intermediate cert signed by such a CA.

b) Use one of their inevitable stock of 0-days to attack whatever browser bob is using at get access that way.  If you look at the results of things like pwn2own private groups have 0-days in popular browsers, so it's kind of inevitable that nation states have the same or better access. Heck you probably wouldn't even need the root CA as most standard browsing will hit some non-encrypted sites that can be easily MITM'd

Frankly I doubt a standard user with any stock OS would stand any chance against  a nation state who had significant interest in getting access to their data.  The shadow brokers releases showed one likely small part of their capabilities.


Let's suppose that someone (Mario) wants to send an email to someone else (let's call him Nicolas). Nicolas' mailbox is filled by a unique server, let's say smtp.gouv.fr (that's a fictitious example). So, whatever Mario does, the email will have to go through that server, transmitted with the SMTP protocol (the one with the 'RCPT' command). Mario would like the From line to be: From: angela@bundestag.de. Note that there are actually two "from" addresses: the one in the From: header (which the recipient sees with his usual mail-reading application), and the one which is given through the MAIL FROM SMTP command (the latter will appear in the Return-Path: header).

Now, although the email has to go through Nicolas' SMTP server, it may make a few hops. The normal mail-sending situation is that the sender uses the SMTP server of his ISP, and that server will talk to the destination SMTP server. Mario's ISP server is smtp.governo.it. Mario can decide to do his telnet (or equivalent, but it always SMTP at the end) either to smtp.governo.it, smtp.gouv.fr, or some other server, e.g. smtp.bundestag.de (the SMTP server of Angela's ISP), or some other server (smtp.buckingham.uk).

There are various things which can prevent Mario from doing so:

Mario's ISP may prevent any outgoing connection from his machine to any SMTP server (i.e. any TCP connection which targets port 25) except if the target machine is smtp.governo.it. Many ISP do that, mainly to prevent zombie machine from spamming widely without any control.
smtp.governo.it may reject the attempt because the advertised "from" address is not an address ending with "@governo.it". The server may enforce such a filter on the "From:" header, or on the MAIL FROM command, or on both. Some (not all) ISP apply such rules.
If Mario contacts smtp.buckingham.uk, that server may reject the attempt because the mail is neither destined to an address in buckingham.uk, or sent with a "from" address in "@buckingham.uk". Servers which forward arbitrary emails from and to the outside are called "open relays" and are generally frowned upon, namely because spammers just love them.
If Mario contacts smtp.bundestag.de, that server may also reject the attempt, although the mail is indeed advertised as being sent by Angela, because smtp.bundestag.de knows that Angela would use a connection coming from one of the IP addresses which are indeed part of the network managed by bundestag.de. If smtp.bundestag.de was not doing that, it would also be deemed an "open relay" (although less open than the previous instance, but partly open nonetheless).
If Mario finds a SMTP server (not smtp.bundestag.de) which accepts to forward the email, or if Mario connects directly to smtp.gouv.fr, then the attempt may still get rejected if the bundestag.de domain uses SPF. SPF is a way for a domain to advertise, through the DNS, some mail-sending policies. Here, bundestag.de would publish with SPF the information that normal emails sent from @bundestag.de people should originate from smtp.bundestag.de and nowhere else. smtp.gouv.fr, upon seeing Mario's connection (or the connection from the gullible SMTP server that Mario found), may then look at the SPF records for bundestag.de, and detect the anomaly. Of course, SPF is not used everywhere, and since it is DNS based it is vulnerable to coordinated DNS attacks ("DNS poisoning" and things like that).
Some big mail providers enforce arbitrary obscure limitations, which may have the same effect than SPF, but in an undocumented and sometimes officially denied way.

So the best bet for Mario would be to either connect with telnet to smtp.gouv.fr (assuming that his ISP lets him do that, and that bundestag.de does not use SPF, or that smtp.gouv.fr disregards SPF information); or he could try to find some hackable or otherwise complacent machine somewhere in the bundestag.de, and use it as an open relay to send the mail through smtp.bundestag.de (which would have the added bonus of making all the headers "realistic", as if Angela had done it herself).


I want to attack a few of your assumptions. They seem, at the face of it, dubious.

Clearly, there is no external threat and only authorized personnel have access to the intranet environment

Famous last words. How sure are you that no malware may be brought on premises unwittingly, via for instance a word document with a malicious macro, a USB pen drive found in the parking lot or similar? This may give third parties access to your internal network.
If the answer is that the network is secure against such threats due to X, then that should be documented as part of the security model for you application. After all, it's an access restriction.

Unless it's an insider threat, however, it's still impossible as there isn't any necessary tools available or downloadable within the environment.

How is it impossible? None of the computers have for instance Microsoft Office, with the possibility to write VBA macros? Or Powershell? Or the possibility to plug in random USB devices with Python on them?

The only threat I can foresee is the transparency of my application. Within my winform application folder, the source files were made available to anyone and users might have the ability to understand it and reverse engineer those source files.

What are you protecting? What is your asset? An application may be an asset by itself, or it may simply be a front end for a backend database, in which case you may not care if someone modifies or copies your application, as long as integrity of backend is preserved. The approaches in those two cases would be totally different.


Can I get an SSL certificate even if external DNS does not resolve

The certificate and DNS record for IP public are irrelevant, you can buy any certificates without publish your sites. All you have to do is to prove you are the owner of that domain by clicking the approval link which send to your domain registration email or a DNS TXT record only.


Do VPNs provide sufficient protection over public wireless networks?

With due considerations to the recent developments in terms of PPTP based VPN connections that lead to compromise of data, usage of Wifi under a VPN is still highly secure for a number of reasons.

Firstly, if you're a casual user who's performing Internet Banking, the practical overhead of performing the exploit procedure and then the decryption of the captured data is quite significant. No local coffee shop hacker would do it, and professionals wouldn't be interested in spending his time on you.

If security is absolutely critical to your transactions then, there are a number of simple additions:

Ensure that the VPN connection is at least an AES-256 with certificate authentication. Do the usual checks to ensure that the certificate is not compromised to a MiTM attack. Eg OpenVPN
Keep the sessions inside your VPN connection them self encrypted. ie. Don't use HTTP, use certified HTTPS, replace FTP by SFTP, etc.
VPNs are over-rated as per me. A good SSH tunnel configured properly works as a lower cost and light weight, easy to deploy solution for encryption. Plus you channel it through your rented server and if you have the need and resources you could for example, setup any custom modifications of the encryption procedure. I'm not encouraging obscurity, just saying you don't have to limit yourself to the current textbook compliance procedures and thus use infamous but more secure encryption techniques.

My point being, for banking, the chances of an attacker being able to break through a VPN encryption, then say a SSH tunnel and then finally your HTTPS web page traffic is extremely improbable, even for highly confidential EOW data.

And even then, banking sessions generally last for a few minutes at max. Apart from certain broken information, there would be no way in any practical banking system with even basic security to use that in order to steal money from you or hack you.


Meterpreter is one kind of shell. So, you can send commands in both a meterpreter session and a shell.
You configure the exploit to use what you want, either meterpreter or some other command shell. Metasploit doesn't decide that for you.


APK Signature Scheme v1 vs APK Signature Scheme v2/v3

Let me quote the official docs:

  v1 signatures do not protect some parts of the APK, such as ZIP metadata. The APK verifier needs to process lots of untrusted (not yet verified) data structures and then discard data not covered by the signatures. This offers a sizeable attack surface. Moreover, the APK verifier must uncompress all compressed entries, consuming more time and memory. To address these issues, Android 7.0 introduced APK Signature Scheme v2.

So yes, JAR signing (v1 signature) does have additional attack vector: malicious mangling of the metadata, or of compressed (signed) entries. For example, uncompressing a specially forged entry, which occurs in trusted context, could cause dangerous side-effects for your system.


Can the school see what you do on the school's Google account even on your own device and at home?

The Google account is administered by the school and they have access to everything created under the account and it doesn't matter what device you use or what wifi you connect to. It's all under the Google account.
But it is very unlikely that the admins will inspect every document unless what is entered triggers some kind of alert in their system, but that will likely be about illegal activities, porn, or bullying. If they even have those types of triggers set up.
So, no, “i’m the hottest girl in school” is not likely going to be noticed.


Benefit of randomly generated column names?

Security by obscurity is not always bad, but here I think it is.

The correct way to judge a security mechanism/implementation/control is "Does it impose more of a burden on the legitimate user than on the illegitimate user?, and is the burden disproportionate to the benefit?"

This poses a significant burden on the legitimate user and makes it rather likely that the legitimate user will misremember/misunderstand the answer and reach a bad conclusion.

I find the single mis-use case you pose to be unpersuasive.  (Others may disagree, but for me, the value is not worth the cost).


It's a bit like asking "How much does a car sell for?" in that there will be intrinsic differences between each exploit, dramatically altering the value. On top of that, the chosen way of monetization will dramatically affect the value also (White hat, black hat, etc). In general I'd suggest black hat methods would probably be more valuable in an absolute sense, ignoring the baggage that goes along with those methods - unless you could consistently produce exploits in which case it would probably be better to be a company such as Vupen.

This article may be of some interest to you - http://www.forbes.com/sites/andygreenberg/2012/03/21/meet-the-hackers-who-sell-spies-the-tools-to-crack-your-pc-and-get-paid-six-figure-fees/

Edit: I apologize somehow I did miss that link to the forbes article you posted. I think the issue you have is that the information that you're after just isn't going to be publicly available. The prices customers would be paying along with who is even buying would be some of Vupen's closest guarded secrets, the same would be going for almost every company who is dealing in this type of product.

For an example of a different exploit market you could see something like 1337day[dot]com who has private exploits ranging from $1 - $7000, but not really the type of exploits you're asking about specifically.


How to protect against an attack where a person claims to be in a position of authority?

as @TerryChia said the correct defence against this kind of attack is strong policies.  In this case users should be trained not to provide passwords to people in person or on the phone regardless of what the circumstances are.

If IT need to log in to a users account they should either use something like sudo (for *nix environments) or if that's not available either reset the users password before doing the work and then reset it again afterwards or alternatively they could use an approved remote control mechanism that has strong authentication requirements.

The key is to set policies up in a way that does not encourage people to break them.  If it becomes the norm that IT staff are asking users for their passwords then when an attacker does the same thing, the users will just go along with it.  However if IT never ask for passwords and it's company policy that they shouldn't, users are far more likely to recognise this as an attack and react accordingly.

As with anything with humans, there's no perfect defence, but correctly designed and implemented policies go a long way to helping.


What is the benefit of adding data encrypting key then store it (encrypted) along with data

I'll give you a concrete example of when / why it makes sense to store the (encrypted) key alongside the data (I happen to have the tab open from answering another question, so why not?):

Android Full Disk Encryption.

In a nutshell: When you turn Android Disk Encryption on, it generates an AES-128 key which it uses to encrypt the drive (called the master key). It then takes your Pattern / PIN / Password and uses that to derive a second AES-128 key which it uses to encrypt and store the master key on disk. You know how the first thing Android does during boot-up is ask for your PIN / Password? That's because it needs it to decrypt the master key so that it can decrypt and mount the main filesystem. The reason for having two AES-128 keys is that if you change your Pattern / PIN / Password, it just has to re-encrypt the master key file, not the whole disk.

Another good use-case is data in transit, for example S/MIME or PGP:

Encrypting large amounts of text / attachment data with an asymmetric cipher (like RSA) is really slow, so what we do is encrypt the bulk data with AES using a random key and IV, then encrypt these with the recipient's RSA public key and attach the encrypted AES key and IV to the massage.

In reference to your point 2.: the exact reason for this choice probably depends on the specific use-case, but one advantage that comes to mind is that you can reveal the key for one row to somebody - for example an auditor - without compromising any other rows in the table. You can also send the data to someone without needing to do the work of decrypting / re-encrypting it (a big saving if the data is large, or you have real-time requirements).


Can a TPM chip check if the bios is still in it's factory setting?

A TPM can only tell if the BIOS and related components have been changed since the TPM was activated. If something has been changed, it can't tell what was changed or when it was changed, nor can it tell if the BIOS was tampered with before the TPM was first activated.


Can a smartphone user prevent Google / Apple / Microsoft from finding out where s/he is? If yes, how?

Yes - disable ALL networking (Mobile, WiFi, Bluetooth, ...)!

You can still make calls and use SMS. But beware of ever turning networking back on, because depending on your settings the phone might log where you have been and then upload that into the "cloud".

But that's not really practical. The most reasons why people want a smartphone require internet access.

There is a complete open-source Android called Replicant. This wouldn't allow Google to track you, but is still not completely open. It is probably the best you can get at the moment, but it supports very few (older) devices and is far from complete.

edit:
And of course remember that while Google/Apple/Microsoft won't be able to track you, your mobile provider always can. And because of various SS7 insecurities, probably everyone else on the planet who cares can also track your location at cell level if he has your number, IMSI,IMEI,...


You got this right. WPS is just a way to provide the data needed to access the AP over WPA2.

Why WPS is insecure

WPS itself is insecure. This is because the PIN which is 8 digits long is split up in two parts. The first part is 4 digits long and the second part is 3 digits long. This means instead of 99.999.999 possible combinatins you only have to try 10.998 (9999 for the first 4 digits and 999 for the last 3 digits) combinations. This is what tools like reaver do: Bruteforcing the WPS PIN.

There are mechanisms to prevent this like delays between attampts and blocking addresses that got the PIN wrong n times but in the end it's just a matter of time till the PIN is guessed.

Why there arent WPS Servers

The capability of a AP to accept WPS authentification is braodcased in so called beacon packets. These packets are send by the AP continiously and contain a lot of metadata about the provided network(s). As the AP is the instance telling someone that WPS is available there can't be any outside servers. Also it wouldn't be a good idea to implement such thing because WPS would still be insecure to use.


If it was possible (with existing technology) to rebuild the private key from the public key, then everybody would be doing it.

Asymmetric algorithms are designed to avoid that. In the case of RSA, rebuilding the private key from the public key is equivalent(*) to integer factorization, which is a hard problem whose difficulty raises quite sharply when the integer size is increased. Current world record for a non-special integer (i.e. a properly generated RSA key) is 768 bits and it took some substantial effort, estimated to about 2000 CPU-year. An important point is that part of the algorithm requires a system with a lot of very fast RAM (we are talking terabytes here), and nobody knows yet how to handle that part with existing technology in the case of a 1024-bit RSA modulus. We have some preliminary designs for specialized hardware which might achieve it, but would cost a lot (not mere millions of dollars) and be rather bulky.

Bottom-line is that you won't succeed in cracking your SSH key, even if you use the best available hardware.

(*) Cracking RSA, as in "computing a forged signature", is not proven equivalent to integer factorization; but rebuilding the private key is equivalent to factoring the modulus.


Reading physical memory frame previously owned by another process to read contents of its memory page

I was curious of this myself once, and wrote a small program under linux that malloc'ed all available memory and dumped it to disk.

It turned out that it was all zeroed out before it was handed to my application.

Later, I also checked the kernel code, and could confirm it was the kernel who did it.

--

I think it makes perfectly sense that it is the OS responsibility to make sure old data is not made available to another process. Where else would you implement such a security measure?

Edit:

I do not remember if I tested against SWAP memory. Due to the disk IO required to zero out allocated disk space (memory), it might be implemented differently.


GnuPG 2.x has a separate gpg-agent that is the custodian of secret keys and that offers no control whatsoever over the encryption parameters of the secret keys within.

Furthermore, --s2k are accepted but ignored when setting a passphrase or exporting a secret key.

There is an issue on the bug tracker about this and, when followed up on the mailing list, the answer was

  No, that is not possible.  Right now the agent always uses AES and S2K
  paremeters which require on the running machine about 100ms for decryption.

So I believe the current situation is that keys are held by the agent as the agent decides is best to meet its speed target on the running machine and there is no way to control it or to export differently. All exports I have tried result in key attributes that you can see like this:

$ gpg --export-secret-key DEADBEEF | gpg --list-packets
iter+salt S2K, algo: 7, SHA1 protection, hash: 2, salt: ...

This reveals the symmetric-key (algo) and hashing (hash) algorithms in use, as defined in RFC4880. The above shows that algo: 7 is AES with 128-bit key and hash: 2 is SHA-1.

The iter+salt tag is the string-to-key mode that GnuPG uses to convert the passphrase (string) into a key. The default value iter+salt means that a salt is added to the passphrase and that string is hashed multiple times (a technique called key stretching which aims to increase difficulty of brute-forcing passphrases).

So that illustrates how GnuPG encrypts secret keys and highlights the fact that you have no control over it if you're using version 2.x due to its use of the gpg-agent.


How can I explain our system admins that AV can't protect our enterprise machines from attacks leverage on USBninja?

It surprises me that you have to. But then, they might be unfamiliar with the USBninja. Explaining what the USBninja does should be sufficient for sysadmins. But the best way is to show them. Buy one. Set-up a HID-script that copies some data from the system to your USBninja. And have them run their anti-virusses at their leisure.

In mass storage mode, the USBninja is detectable by anti-virus. It will behave as a storage device, which might be useful if you want to extract larger chunks of data. However, you will probably not put a virus on it.

Experiment a bit with HID scripts. Get a few from the Internet like:

DELAY 5000
GUI r
DELAY 1000
PRINT notepad
ENTER
DELAY 1000
PRINT Hello, World!

In general, a short presentation, followed by a demo should be sufficient.

First explain what anti-virus does (signature detection, sometimes program behaviour)
Explain what a USBninja does. Especially, explain the HID-mode. Make them understand that anti-virusses do not protect from keyboards.
Demo-time!
For fun, buy some cheap USB-cables that you leave scattered around the room. If they understood the message, no-one will dare to use those cables.


How likely are Evince, XReader or Adobe Reader with scripts disabled, to be exploited by a malicious file?

The best practise¹ would be to open them on a Virtual Machine (or even in a separate, physical machine that you could easily reimage after each use).

On Qubes OS, the ability to open a PDF on a separate, disposable VM is (mainly) integrated in the system: How Qubes makes handling PDFs way safer

They also include an option to create a trusted PDF, whiih basically created an image-based pdf in a separate VM.

The PDF Redact Tools can also be used to create clean, image-based, PDFs. It should as well be run on a separate VM.

¹ Assuming you are going to open them


What's a "safe" URL shortening algorithm?

Entropy is your friend.  Using only alphanumeric characters (special characters are best avoided in this case because they often need URL encoding, which complicates things) you have a "language" of 62 possible characters to choose from.  For a string of length X made from this "language", the total number of possible strings is simply:
62**X

If you start blocking an IP address after Y failed attempts then the odds that an attacker with a single IP address will guess a code are:
Y/(62**X)

But imagine an attacker can easily switch IP addresses, so let's imagine they have a million IP addresses at their disposal (note: the number will be much larger if you support IPV6).  Therefore their odds of success are simply:
(1e6*Y)/(62**X)

Finally note (h/t @Falco) that the above assumes the attacker is looking for a particular code.  If you are worried about someone finding any code then you need to further multiply by the number of active codes you have at a given time, which depends on how often they are created and how quickly they expire.
Given all of this though, you just have to decide how low you want the probability to be, plug in your Y, and solve for X.  As a simple starting point I usually suggest a 32 character alphanumeric string (make sure and use a proper CSPRNG).  If you block an IP after 1000 failed attempts then an attackers odds of finding a specific code are:
(1e6*1000)/(62**32)

Which is 4.400134339715791e-49.  Given those odds, it's more likely that the attacker will win the lottery 4 or 5 times in a row before they guess a code.  You could have billions of active codes at a time and the odds of guessing any one would still effectively be zero.


What is s3.amazonaws.com, and why is Chrome blocking it?

s3.amazonaws.com is an endpoint for a cloud file storage product offered by Amazon Web Services (AWS) and is used by many websites and apps (albeit usually behind the scenes, but you can serve files from it directly too).

Seeing references to that domain is definitely not inherently malicious, however given that you can store just about any file in S3 there's no guarantee that it isn't being used to store some malicious files (among the overwhelmingly legitimate files). AWS credentials are a valuable target for hackers so it's possible the owner of the account has been compromised.

Chrome and Comodo may know that attributes such as the size, checksum, name, etc. of the file match that of known malware which is why they're blocking it (rather than necessarily because it's served from s3.amazonaws.com).

I'd recommend reporting it via the AWS abuse form or by emailing abuse@amazonaws.com. If it is malware then they'll most likely remove it and contact the account owner. AWS is usually extremely proactive about security issues.


If there still any value for any website to have an EV certificate?

Effectively, no, since most browsers now treat them the same as non-EV certificates.

Since fall 2019, the green bar and company information has been
removed from all major browsers, such as Google Chrome, Mozilla
Firefox, and Microsoft Edge (with Apple’s Safari browser having
removed these indicators even earlier). (ssls.com)

If the difference isn't presented to the user, is there really a difference?
As you've shown, there is more information presented when you click through to an EV certificate, but how often will an end user click through?  How many end users will understand that seeing the company name there implies anything different about the trust level of the certificate?  The decision to bury this information has devalued it, and we will see less sites investing in an EV certificate as a result.


As for example described in Wikipedia the PEM format requires a begin and end label, i.e. -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- . What you have here does not have such labels and thus cannot be PEM.

It is instead a base64 encoded DER representation of the certificate, prefixed with the SHA-1 fingerprint of the certificate. I.e. what you have here is

bf55348d696395689d5c461bc0f092ecabcdb6ca,MIIGaTCCBVGgAwI....pxhS2kQw==
         sha1_fingerprint_as_hex        ,der_encoded_certificate_as_base64

To get the actual certificate you can decode the base64 part and feed it into openssl x509:

$ echo MIIGaTCCBVGgAwI....pxhS2kQw==  |\
     base64 -d | openssl x509 -inform der -fingerprint -text

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            04:6b:df:0f:d9:20:41:ae:b2:d3:5a:93
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=BE, O=GlobalSign nv-sa, CN=GlobalSign CloudSSL CA - SHA256 - G3
        Validity
            Not Before: Jul  5 06:10:28 2019 GMT
            Not After : Jul  5 06:10:28 2020 GMT
        Subject: C=US, ST=Delaware, L=Dover, O=Incapsula Inc, CN=incapsula.com
    ...
SHA1 Fingerprint=BF:55:34:8D:69:63:95:68:9D:5C:46:1B:C0:F0:92:EC:AB:CD:B6:CA
-----BEGIN CERTIFICATE-----
MIIGaTCCBVGgAwIBAgIMBGvfD9kgQa6y01qTMA0GCSqGSIb3DQEBCwUAMFcxCzAJ
...
eKCQeesTlOpxhS2kQw==
-----END CERTIFICATE-----


How to enable ONLY TLS 1.2 in Java, blocking SSL TLS1.0 and TLS 1.1

Check out SSLSocket.setEnabledProtocols(). Here are the valid names for protocols.


What are the pros and cons of using sha256 to hash a password before passing it to bcrypt?

Bcrypt as stated in the Link is limited to 72 Characters.

SHA256 may have an OUTPUT size of only 32 Bytes, It's Message input is ((2^64)-1)\8 or roughly

2305843009213693952 Bytes (assuming a char is 8 bits)

To Bcrypt it's receiving a 32 Byte passphrase to encrypt, To SHA256 that could be a 400 Char data stream (IE password).

So no, you're not losing entropy on this, you're overcoming a limitation in Bcrypts design (If you want to call it a limitation.

Link on SHA2 discussing is sizes:
https://en.wikipedia.org/wiki/SHA-2


You defend against malicious actions by first identifying those malicious actions. Ransomware can show itself by high numbers of "rename" actions. That's a quick and easy way to identify malicious actions that are unlikely legitimate.

If doxware does not do this, then yes, you need another "indicator of compromise" to look for. Like a lot of other malware, looking for high numbers of file access and high outgoing bandwidth can be one way of doing that.

As with ransomware, whitelisting processes and applications can block infections before they occur.

I think the reason why we are not seeing a huge outbreak of this sort of attack is because an opportunistic attacker is not going to have the resources to handle a million user's files, and trying to collect them all would make them stand out on the Internet (high volumes of traffic). So, it will be targetted attacks where this would be used. But that is not new at all. Many malware have existed for a long time that do this (RATs being the first one that comes to mind).

The more dangerous variant is a 'doxware' that only looks for a particular file or a small set. This would be impossible to detect.


Any there any tools like Burpsuite that fully support HTTP/2?

Information Security SE isn't really for product recommendations, but the subject is covered pretty well in Stuart Walker: Testing HTTP/2 only web services.
The reason why the tools haven't been developed into this direction is probably because debugging HTTP/2 itself hasn't been that common with such tools. When testing web application security, the target isn't the protocol used to transmit the content, but the application. Most servers do support fallback to HTTP/1.1, and you can always put a reverse proxy in front of those that don't.


Is the Google address being spoofed on my computer?

Most likely not. IPv6 support is still quite patchy in many parts of the world. The delay is most likely caused by bad routing or network packets having to go through too many hops. You can test out your IPv6 connection here.

The hosts file is used to bypass DNS and make your access to websites matching domains listed slightly faster, not slower.

A whois lookup on 2607:f8b0:4009:801::1011 shows that the address belongs to Google Inc. Hackers would most likely direct you to a site they own or control, in which case, it wouldn't be Google.

To avoid the situation of websites taking longer time to load, you can turn off IPv6 on your network configuration setting to prevent DNS from resolving to an IPv6 address. Further, if you are using DNS servers from your ISP, you can try change them to Google's DNS servers on 8.8.4.4 or 8.8.8.8 as they seem to be more reliable.

For verification of the Google website, access using HTTPS and follow the detailed instructions given in thexacre's answer above.


Why are the first 16 bits of the message digest not encrypted in PGP?

RFC 4880, the standard for the format of PGP messages, says:

The high 16 bits (first two octets) of the hash are included in the
Signature packet to provide a quick test to reject some invalid
signatures.

However, you are thinking it wrong. Signatures are not encryption, and signatures are not encrypted. In fact, given the value of the public key (which is public) and the signature itself, one can recompute the complete hash value of the message which is signed (at least for RSA, which is technically known as a signature algorithm with recovery). The first 16 bits are just a helper so that software can avoid many modular exponentiations when it is looking for the "correct" public key among a set of candidates; they save a few milliseconds worth of computation, that's all.

A generic note is that signatures can leak information on that which is signed; so if you sign and encrypt a confidential message, then you should, conceptually, either sign the encrypted message, or encrypt the signature along with the message contents as well. OpenPGP uses the latter method.

When a message is just signed, not encrypted, then it makes no sense to hide the message hash, since the message itself, by definition, is transmitted as cleartext.


What security benefits does ALPN bring to TLS?

ALPN by itself does not offer any security benefits or speed improvements. But, if your application needs a negotiation of the application protocol then this negotiation can be done already inside the TLS handshake and thus does not need additional roundtrips. And this is where the speed improvement comes from.

The major use of ALPN is inside the browsers to tell the server that the client supports HTTP/2. If the server supports this too it will tell the client inside the TLS handshake already so that the client will start with HTTP/2 immediately after the TLS handshake instead of needing another negotiation. And since HTTP/2 offers more performance than HTTP/1.1 independently if TLS or not is used the choice of this protocol over HTTP/1.1 adds to the speed improvement.


Ensuring security of a Disaster Recovery Plan

You appear to be discussing accessing the Plan itself and not the actual technical implementation of Disaster Recovery. The technical aspects can craft an answer for you.

When the disaster recovery event actually happens the IT aspects will probably include retrieval of off-site data storage and activation of systems for recovery of same. Let's consider your question from the technical implementation and see how it impacts close hold storage.  As a given, the Plan addresses much more than IT but IT confidentiality appears to me to be a gating factor.

For the Plan to work it needs to be more than just revised every year or so it needs to be practiced (repeatedly) and all involved need to know their role and have reasonable expectations of what will be happening (e.g. what building in what city do I go to to get my copies of my contract filings)

I would suggest many eyes need to see this plan nearly continually (new hires, role changes, etc.).  Therefore, SharePoint or some company cloud storage available to all would be the first place I would store the Plan.  Personal copies for key recovery personnel that are tested for their safekeeping and existence in training would be another good place. Locked in a safe deposit box seems to be a very bad place for the Plan.


Force SSL/TLS client cert authentication even if server does not request it?

The client won't send a certificate unless the server asks for it with a Certificate Request message (see the standard, section 7.4.4). If the server does not ask for a certificate, the sending of a Certificate and a CertificateVerify message from the client is likely to imply an immediate termination from the server (with an unexpected_message alert). The wording of the standard is not overly clear on that subject, but it still includes this paragraph in section 7.4:

  The handshake protocol messages are presented below in the order they
     MUST be sent; sending handshake messages in an unexpected order
     results in a fatal error.  Unneeded handshake messages can be
     omitted, however.  Note one exception to the ordering: the
     Certificate message is used twice in the handshake (from server to
     client, then from client to server), but described only in its first
     position.  The one message that is not bound by these ordering rules
     is the HelloRequest message, which can be sent at any time, but which
     SHOULD be ignored by the client if it arrives in the middle of a
     handshake.

This rather strongly suggests that an unexpected Certificate message from the client will not be ignored, and instead will "result in a fatal error".

Now you could imagine an active modification by an Man-in-the-Middle entity, who injects an extra Certificate Request message in the flow from the server, and blocks the Certificate and Certificate Verify from the client. This is possible, since the initial handshake is performed, out of necessity, with unprotected records.

However, this will make the handshake fail when the Finished messages are exchanged. These messages are protected (they occur after the switch to the newly negotiated security parameters). The contents of the Finished messages are a hash of all handshake messages sent so far. Since the client and the server did not see the same messages (from the point of view of the client, there were extra Certificate Request, Certificate and Certificate Verify messages), the hash values won't match, and the client and server will drop the connection.

So not only it is unclear what an attacker would gain by forcing a client authentication that the server did not ask for, but it will also not work at all because of the way the Finished messages are computed.


This is a seriously broad question and probably off-topic.

Still, emkei.cz is a free online mailer. It does not require an account or any form of registration. This means that any information contained in the email itself will be useless when it comes to identifying the ultimate sender.

The legal way for authorities to identify would be to subpoena the service provider itself.
If you notice the small print at the bottom, they say:

  This service does not violate the EU law. We are not obliged to keep
  any logs. FinalTek.com and Forpsi.com are neither owners of this
  service nor responsible for its content.

At a guess, I would say they might not be logging source IPs of email senders, so even a subpoena would be fruitless.

Of course, those are the normal and legal ways to find out who used the service. Help with any alternate methods is definitely off-topic here.


If a website filters out XSS-related terms, is it still potentially vulnerable?

So, my question is, would this website still be vulnerable to cross-site scripting, or is it safe due to the filter it uses?

It's not safe. You didn't fully describe your filtering mechanism, but a blacklist-based XSS filter is guaranteed to leave some loopholes.

Examples

Do you consider the href attribute of link tags? A click on this link would trigger:

Click me

If you filter out javascript:, are your checks case-insensitive?

Click me

And do you consider different ways of encoding? E.g.:

Click me

Do you consider frames? It's certainly not enough to filter out javascript: since an attacker could also use other schemes, e.g.:

If you're thinking that the ">

Again, there are many ways to encode this, e.g.:

The list goes on. (What about SVGs, forms, meta tags, obscure vendor-specific protocols, embedded flash applets, CSS, ... ?)

The correct approach is to use a whitelist of allowed tags and attributes, and parsing the resulting DOM tree instead of regex-based string replacements.


Should a server or a client be able to verify a client/server certificate - intermediate certificate chain with a known root ca?

Not a complete answer (yet?), but:

Yes OpenSSL library called (directly or as here via libssl) by a program like FreeRADIUS can verify a received chain; no your commandline openssl verify does not verify a chain. This is covered in https://stackoverflow.com/questions/44375300/openssl-verify-with-chained-ca-and-chained-cert (mine) but that is downvoted and suggested offtopic, so I'll copy the relevant part here:

openssl commandline verify reads only one certificate, the first one, from the file given as operand, or from each file if more than one is given. This differs from the files specified with the -CAfile -trusted -untrusted options which can (and typically do) contain multiple certs.

Your file clientcert_intermediatecert_chain.pem contains the client cert and the intermediate cert in that order. Only the client cert is used, the intermediate cert is ignored, and as a result you do not have a valid chain to verify.

To use commandline to mimic/test the validation done by a receiver (for a client cert chain, the server) supply the leaf cert as the operand and all other transmitted (chain) certs (here the one intermediate) with -untrusted, and the anchor(s) plus any 'known' intermediates in the truststore either explicit or defaulted (your -CAfile root is fine, although there are other valid ways).

As to the real problem (Y) with FreeRADIUS: Are you sure the client is sending the chain? Do you have a trace?

As an alternative: if the client (or in general peer) doesn't send the needed chain certs, but they are in the local truststore which is arguably a spurious thing to do, OpenSSL will use those. You might try adding at least temporarily the intermediate cert to either the file you use for CA_file or the hashnamed directory you use for CA_path.


Why does SSLStrip work on some https sites and not others?

Those sites (and some more) use public key pinning with HSTS, whereas the browser does not accept other certificates or a downgrade to http.


Blackberry QNX / Playbook encryption details

Source Blackberry Knowledge Base

  "Security of work and personal data on the BlackBerry PlayBook tablet"

Does the tablet store any work data persistently in the work file system?

No.

When a tablet is connected to a BlackBerry® smartphone using BlackBerry® Bridge™, the tablet temporarily stores work data in the work file system on the tablet. The work file system is encrypted using XTS-AES-256. The keys that the BlackBerry® PlayBook™ tablet uses to encrypt the work file system are encrypted using the BlackBerry Bridge work key. The tablet stores the BlackBerry Bridge work key in RAM only.

When the Bluetooth® connection between a tablet and a smartphone closes, the tablet and the smartphone each delete their copy of the BlackBerry Bridge work key. All of the work data that is stored on the tablet is encrypted with keys that are encrypted using the BlackBerry Bridge work key, and both copies of the work key are deleted. This data and key encryption means that it is not possible to decrypt the work data after the Bluetooth connection closes and the smartphone and tablet delete their copies of the BlackBerry Bridge work key.

What is XTS-AES?

XTS-AES is an IEEE-approved Advanced Encryption Standard mode for disk encryption that provides protection against manipulation of encrypted data. XTS-AES-256 uses 512-bit cryptographic keys.

Does the tablet encrypt personal data?

No.

Can I disable the feature that allows work applications to attach personal files to work email messages or calendar entries?

No.

Is the cryptographic module on the BlackBerry PlayBook tablet FIPS validated?

Yes. The cryptographic module on the tablet has received FIPS 140-2 certification.

Can I set a password on a tablet?

Yes. A user can configure the tablet password and timeout options using the Options menu on the tablet. If you set a password for the tablet, you must provide that password to log in to the tablet.

Is work data protected by the smartphone password?

Yes. After a BlackBerry PlayBook tablet user connects the tablet to a BlackBerry smartphone that requires a password, the tablet automatically requires the user to provide the smartphone password when the tablet accesses any smartphone data. Smartphone data can include email messages, calendar entries, tasks, memos, BlackBerry® Messenger messages, intranet content, files, or attachments that the user views on the tablet.

The requirement to provide the smartphone password to access work data is independent of the tablet password that a user may set.

Do the IT policy rules that control the password security level of a smartphone extend to a tablet?

Yes. If a user connects a tablet to a smartphone that is associated with a BlackBerry Enterprise Server, any IT policy rules that control the password security level of the smartphone apply to the smartphone password that the user must enter to access work data on the tablet.

What password security level is enforced if I connect a tablet to a smartphone with one set of IT policy rules, then disconnect and connect the tablet to a smartphone with a different set of IT policy rules?

While the tablet is connected to the first smartphone, the password security level that is set for that smartphone is enforced. This security level applies to the smartphone password that a user must enter to access work data on the tablet. It does not apply to the tablet access password that a user may set on the tablet.

When you connect the tablet to another smartphone, the tablet deletes the work file system that temporarily stored work data associated with the first smartphone. While the tablet is connected to the second smartphone, the password security level that is set for that smartphone is enforced. This security level applies to the smartphone password that a user must enter to access work data on the tablet. It does not apply to the password that a user may set on the tablet.

Additional information can be found here (also see the links in the comments)

http://supportforums.blackberry.com/t5/Tablet-OS-SDK-for-Adobe-AIR/BlackBerry-PlayBook-File-System-Layout/ta-p/773327?CPID=E10C020&Date=040312

Alias   Path
File.applicationDirectory   /accounts/1000/appdata/(appdir)/app/air
File.applicationStorageDirectory    /accounts/1000/appdata/(appdir)/data
File.desktopDirectory   /accounts/1000/appdata/(appdir)/shared/documents
File.documentsDirectory /accounts/1000/appdata/(appdir)/shared/documents
File.userDirectory  /accounts/1000/appdata/(appdir)

  Now, in that list, the (appdir) folder (which refers to a folder named
  for your app's Package Name and Package Id joined with a dot, as in
  "Foo.QXBwRXZlbnRzICAgICAgICA") is not writable by your app.  The app
  has read/execute permission only, and only root can write to it.


How to prevent Insecure Direct Object References?

Insecure Direct Object Reference is essentially a combination of two issues, in the most common case: enumerable identifiers used for externally exposed objects, and a lack of sufficient checking for access rights to those objects. The first of these isn't actually required, but makes detection of the issue harder (guessing a GUID, for example, is much harder than incrementing an integer).

Therefore, fixes ideally address both points. The application should verify that the current user has permission to access the object, every time access is attempted. If a user has access to record 3 and no others, any attempt to access record 4 should be rejected. Note that in some cases, just checking on read access is insufficient: if they can write to a record, even without being able to read it, it may allow further compromise. For example, if a PUT request made to /user/1 contains a password value, it is important to check that the same PUT request cannot be made to /user/2, even if it is known that GET /user/2 is rejected.

Secondly, object references can be modified to be user-specific. This can prevent exposing information which can be commercially sensitive: if your client id field is 1045, and you signed up to a site yesterday, you can make a pretty reasonable guess that there are unlikely to be more than 1050 clients. This could be exposed through profile screens at paths such as /profile/1045/edit, or through a parameter being passed in a POST request, among other ways. If, however,  the path was /profile/edit, and the client id was determined by the server based on the currently active user session, this information is not exposed.

Obviously, in some cases, this isn't an appropriate method: in a CRM system, multiple users need to be able to access the same records, for example, as well as being able to share them. In this case, there needs to be some way to reference them across user accounts. A hash of the object id would be one option, although this needs to be used in conjunction with access controls.

For things like permissions, however, there is no particular need for users to be able to share an identifier. It's more important that they can only set values which are appropriate to their user level. In this case, assigning a user specific identifier to those values which they should be able to access can prevent them even being aware of other values. By performing a server side mapping - 1:read only, 2:read-write for standard users, but 1:full control, 2:read only, 3:read-write, 4:delete for administrative users, say - and then processing that when the data is stored, standard users never even see that there are higher levels, and even if they did, would have no way to set them: attempting to copy an admin user's POST request setting the access level to 1 would result in it being set to read only, rather than full control.

It is important to note that without insufficient access controls, the amount of information exposed through direct object reference is limited: it might not matter than people can tell how many objects of a given type exist (e.g. Twitter uses (big) integers for tweets), and just preventing unauthorised users from accessing other objects is the important part. Direct object references can be appropriate in some cases, usually where there is a requirement to share a common identifier between users.


Does incognito mode prevent cookie-theft attacks?

Assumptions
I'm assuming that since you've indicated incognito mode, that you are not talking about attacks where an actor has code running on your machine or remote access.
Background
Cookies are stored on your computer and linked to a specific website that has requested them.  When you get a cookie from gmail at login, it will be presented to gmail on every subsequent request from that browser session and (as you correctly identified) would not be presented to gmail if you were in incognito.    However, you don't need to be in incognito for your cookie from gmail to be kept secrete from any other website.
Exploits
For an exploit to get a cookie from your browser that doesn't belong to it, you'd have to break the sandbox. This could get you access to cookies that were not intended for the website.  Since each tab/window of chrome are separate processes, you do get more isolation by using incognito.
Answer

does incognito mode prevent 100% of cookie-stealing methods of identify fraud

No, there is nothing you can do to prevent anything 100%.  There is no such thing as being "Secure" only "More Secure".  If someone hits you with a browser escape and a privilege escalation, they can do anything they want on your machine including stealing your cookies.


Is there any conceivable reason to prevent a password change in an authentication system?

I agree this must be bad design. You may want to have password stability over certain periods for synchronization across systems or when a new system is integrated into a larger system. Except for those circumstances, you want to be able to change a password  whenever a password may have been exposed, which could be anytime.

The only thing I can think of is that the password is used for a secondary purpose, such as making a digital signature of every person who read a particular document. In a case like this where the password is used to keep a record of an individual's action it would be complicated or confusing to change passwords. However the easy solution is to issue a password for authentication and another cryptovariable for digital signatures.


Any security value in limiting time of day for VPN?

I have encountered and even configured this. The idea is to reduce the attack surface by only allowing remote access during the time when remote access is expected.
Your friend is doing something unexpected. And that's OK. The security people should account for and support this (if it is in line with business need - your friend might actually be violating a specific work policy, too, or not, but I've seen business policies like this for various reasons).
So, yes, this time restriction is normal and it is for legitimate security reasons. But that doesn't necessarily mean that your friend cannot also get a security exception so she can do her work.


How to protect WordPress from brute-force attacks?

If you have an access to the server then you can install fail2ban.

You will need to set up jail for the wordpress /etc/fail2ban/jail.d/wordpress.conf

[wordpress]
enabled = true
filter = wordpress
logpath = /var/log/auth.log
port = http,https

$ service fail2ban restart

For more details check Bjørn Johansen: Using fail2ban to block WordPress login attacks.

Make sure that you are not using default username (admin), and use strong password.

Another way to protect against brute force attack is to make restriction on wp-login

<Location /wp-login.php>
                Order deny,allow
                deny from all
                allow from 192.168.1.1 <- put your ip here
</Location>

Another solution is to protect wp-login with htaccess:

# Protect wp-login
<Files wp-login.php>
AuthUserFile ~/.htpasswd
AuthName "Private access"
AuthType Basic
require user mysecretuser
</Files>

More about protection against brute force attacks you can find here:
https://wordpress.org/support/article/brute-force-attacks/


WLCTL protocol detected by sniffer in an Android tablet

WLCTL (Web Listener Control) Utility is a UNIX utility, so I would recommend getting some sort of terminal emulator app and run the command "top" or "htop" to display the running processes, once you sort through the necessary normal processes and isolate the one that is sending out these packets, you can run the command "pidof [process name] " without the brackets and apostrophes and the output should be a number which uniquely identifies the process. From here its a simple command "kill [process id number]" again without the brackets or apostrophes.


If I storing my own cards in a database. Does this fall under PCI compliance framework?

PCI is about protecting consumers and "consumer data".   I don't think the PCI-DSS applies here,  although it isn't a good idea.  SQL Injection can be used to read these values,  it is slightly better to hardcode these values in a configuration file,  it is also a more appropriate design.


How difficult is the USB firmware attack?

After reading different sources I would like to answer this myself.

Currently Karsten Nohl has not released details or tools about how this works. With the given information it should be difficult to reproduce his work.

This will change on August 7 when he will release proof-of-concept tools at BlackHat 2014. There are three widely spread USB controller chips. From what is know Nohl has reversed engineered the firmware of at least the most used controller Phison.

From an attacked USB device he can attack the computer. If is able to get administration access on the USB host he is also able to flash other USB devices from there. That could get interesting...

Depending on what Karsten Nohl will release this could be even used by script kiddies.

Update

Comments asked about sources. I only got a german source but you can use a translator. Nohl did some interviews with different German news agencies.

Here two important parts:

  Laut Nohl kommen bei USB-Speicher-Sticks fast nur Controller von drei Herstellern zum Einsatz; sehr weit verbreitet sind die von Phison. Wie Nohl im Rahmen seiner Forschung herausfand, hatten bereits andere deren proprietäre SCSI-Befehle analysiert. Nohls Team gelang es, nach einer Analyse der Firmware auf diesem Weg einen ganz normalen USB-Speicherstick umzuprogrammieren

This is saying that Phison is widely used and in a following sentence that Nohl analysed the SCSI commands and was able to reprogram the USB thumb. It does not directly say he reversed engineered the Phison.

  Um dann wiederum weitere Sticks zu infizieren, benötigt der Schadcode zwar Systemrechte...

Here they are saying they can infect other devices if they can get system rights.


Does an authorization code grant rely on sessions?

After the initial authentication, what goes out on each subsequent API call for authentication?

For API's:

Each successive API call would use a token (Access token). You would be using https://oauth.net/2/grant-types/client-credentials/ (API/Resource focus)
Access is constrained by scope and linked to the Access Token. This prevents calls to unapproved API's for a given token (https://oauth.net/2/scope/)

For webapps:

You would likely use https://oauth.net/2/grant-types/authorization-code/
You are correct when you say you would set up a session using something like a cookie to identify the user.

On a previous project we used Auth0 (I am not in any way affiliated). They have some sample apps - https://auth0.com/docs/quickstarts . I use Java primarily, so I have linked those as well. It is also free to sign up and play around:

API > https://auth0.com/docs/quickstart/backend/java-spring-security
Webapp > https://auth0.com/docs/quickstart/webapp/java-spring-security-mvc
SPA > https://auth0.com/docs/quickstart/spa/vanillajs

Hope this helps?


Should BCRYPT be used for client-side password hashing

It's just the other way round, BCrypt does not encrypt the password with a secret key, rather it uses the password as the key to encrypt a known text. In the setup where the key is generated, it uses both salt and the password (variable EksBlowfishSetup.key), to generate a key (variable bcrypt.state) used for encryption.

bcrypt(cost, salt, input)
    state \gets EksBlowfishSetup(cost, salt, input)
    ctext \gets "OrpheanBeholderScryDoubt" //three 64-bit blocks
    repeat (64)
        ctext \gets EncryptECB(state, ctext) //encrypt using standard Blowfish in ECB mode
    return Concatenate(cost, salt, ctext)

EksBlowfishSetup(cost, salt, key)
    state \gets InitState()
    state \gets ExpandKey(state, salt, key)
    repeat (2cost)
        state \gets ExpandKey(state, 0, key)
        state \gets ExpandKey(state, 0, salt)
    return state

BCrypt can be seen as encrypting with throwing away of the key.


Is pressing random keys a secure way to seed a key generator?

Yes, but that's how you're getting randomness anyway. In Linux and most other operating systems, the exact time in nanoseconds that a key is pressed is recorded and injected into the entropy pool. This pool is used to seed the CSPRNG that powers /dev/urandom and other cryptographic random APIs.
The similar /dev/random character device is what we describe as blocking. It assumes that all used cryptographic functions are broken (a worst-case scenario) and so will only output randomness when it thinks it has "collected" enough entropy. When you type keys, the operating system uses that as a source of entropy and increases the entropy estimate, causing /dev/random to unblock. This speeds up the entropy collection by programs using that device. Now that doesn't mean that the program sare doing the right thing. They should have just used /dev/urandom which does not block and is still quite cryptographically secure. You should take a look at https://www.2uo.de/myths-about-urandom.
A related document on best practices for randomness generation is BCP 106.


Install the same certificate on public facing servers and dev / qa servers

You are not just importing the public certificate. You are also importing the private key that belongs to it.

I think the main implication is that you will be giving an untold number of dev and qa people access to the production server's private key. That means with a quick file copy, they can go home and do man-in-the-middle or phishing attacks against your user base.

Apart from insider threat, since I assume your dev and qa environments have less security hardening than your prod environment, you are also lowering the bar for hackers to steal the prod server's private key . For example, a compromised dev machine (say from an email attachment) probably has an easier time accessing the qa system than the prod system.

Better to have your prod system and dev / qa systems using different private keys.


The password hashing business is about turning a password (which is weak, by definition) into a sequence of bits suitable for storage (password verification token) or use as an encryption key (in which case we are doing password-based key derivation). In order to tolerate the use of passwords, we have to follow some strict rules:

Use slow hashing with a lot of iterations (that's easier said than done, so don't get creative and use a well-studied standard like bcrypt or PBKDF2).
Never ever reuse a salt value for another password instance. Indeed, if two passwords are hashed with the same salt, then attacking one will allow attacking the other "for free".

However, once you have turned the password into a key, you can use it as any key. If your encryption system is not laughably frail, there should be no problem with using the same key to encrypt many files. In the case of something AES-based, this implies, indeed, a new IV for each file. The properties of that IV depend on the actual encryption mechanism; AES-CBC requires a random, uniform, unpredictable IV, while some newer modes like GCM only need a non-repeating IV and thus work well with a simple counter.

Note that many password-based encryption scheme use a salt-and-iterations system to hash the password into a sequence of bits containing both the key and the IV. Such systems cannot be used for more than one file; otherwise, you will reuse the IV, and that's a deadly sin (usually worse than reusing a salt, which is already quite bad). If you want to reuse the key resulting from the password hashing, then you MUST generate a new IV for each encryption run.

Also, note that if two files are encrypted with the same password-derived key, chances are that their headers will include the salt (you have to put it somewhere, so that it is available for decryption), so you will leak the information that both files are protected with the same password, and thus have the same source. Depending on your context, this may or may not be a problem for you.

Other people have found it convenient to use the simple expedient of storing their ten files into a single Zip archive and encrypting that as one file. Depending on your context, this may be applicable (or not), and is much simpler to implement without botching the crypto layer. In general, designing your own encryption format and assembly of algorithms is a path fraught with perils, and you cannot know whether you did it right or not (security is not functionality: it cannot be tested).


How to stop/detect someone else registering a certificate for my domain

This is really a matter of each CA's policies.  Most of them require proof of ownership of a domain before issuing a certificate.  Even with cheap CAs this usually involves either verifying an e-mail can be received by a WHOIS contact or making entries in the DNS records for the domain.


What are the privacy concerns about this?

Content analysis by intercepting SSL as an active man in the middle can only be done if the client trusts the CA of the man in the middle because this CA issues a new certificate. Thus it will usually only work transparently in company networks where the systems are managed in a central way and such CA's can get installed. It will also work if the user overrides the warnings or if the software does not properly validate certificates.

If the interception is done by a trusted party (i.e. employer or similar) which has control to the system anyway then the additional privacy implications due to SSL interception are probably less a problem because this trusted party has access to the system already and thus could in theory also grab the plain data outside the encrypted connection.

Privacy implications are more severe if the user is not aware of the inspection and thus transfers sensitive data in the believe that they can not be intercepted. This is especially problematic if these are private data. But, use of company controlled systems for handling sensitive private data is a problem anyway and is not restricted to SSL interception.

Apart from these legal interception there are illegal ways by using trusted certificates known to the attacker. From my understanding of the question this is not what you ask about, but see the story about Superfish adware for an example.

  Is there a way for websites to prevent this from happening to their users?

It is hard for websites to detect SSL interception but it would be possible in many cases. Since the SSL interception essentially terminates the SSL connection from the client at the MITM proxy and creates another SSL connection from the proxy to the server the TLS handshake hitting the server will be from the MITM proxy and not the original client. By fingerprinting the handshakes and comparing to typical browsers and MITM solutions it is possible to determine if SSL interception is probably done. For more details see the chapter TLS Implementation Heuristics in The Security Impact of HTTPS Interception.

But, in reality the necessary information to fingerprint the TLS stack are not exposed to the application but are kept inside the TLS engine of the web server. Thus a web application itself can usually not determine if TLS inspection is done or not.

Another way to deter SSL interception from the server side is to require client certificates. Most SSL interception solutions cannot deal with these and even if they could they would need to re-issue the client certificate the same way as they do with the server certificate which can be detected by the server because the issuer CA is not trusted. Unfortunately, this would mean that you would first need to issue certificates to all your clients which they need to install. While useful if you want to use these certificates for authentication of the client anyway it would be a logistic and usability nightmare in most cases.

  Does HSTS prevent it?

HSTS just says that the site should be accessed by HTTPS only. Since the site still gets accessed by HTTPS even though the traffic gets intercepted this header will not help. More useful in theory might be certificate pinning, either by using the HPKP header or using built-in pinsets. But while key pinning would detect if the certificate got changed due to SSL interception it is explicitly disabled if the new certificate was issued by a CA which got explicitly added as trusted. This is done to support legal SSL interception like done in companies but also within many antivirus products.


How can an organization know my age based on my IP address?

Short answer: they can't.

Long answer: An IP address does not carry any information about the ages of any users behind them. The only thing they can do is correlate different activities from that IP address, hoping to find accesses to a service that does some kind of age verification, and then boldly deduce that since one user behind that IP address was verified to be over age, all of the users behind that IP address must be.


If I find a Microsoft Vulnerability do I get credit for reporting it directly to Microsoft?

Yes! Microsoft's policy seems to be that if you report the vulnerability to them responsibly, you'll get a mention in the acknowledgments section of security bulletins. I would also expect some back and forth correspondence on the issue that you could keep as further proof.

  When you see a security professional acknowledged in a Microsoft
  Security Bulletin, it means that they reported the vulnerability to us
  confidentially, worked with us to develop the patch, and helped us
  disseminate information about it once the threat was eliminated. They
  minimized the threat to customers everywhere by ensuring that
  Microsoft could fix the problem before malicious users even knew it
  existed.

The acknowledgements section does indeed include considerable detail, naming individuals and organizations. For example, the October 2013 bulletin mentions (among others):

xxxx.xxxx@gmail.com, working with HP's Zero Day Initiative, for reporting the Internet Explorer Memory Corruption Vulnerability (CVE-2013-3872)

It would certainly look very good on your CV!


Is it possible to see who is connected to the guest network on a TP-Link WR840N?

For clients, go to DHCP and DHCP Client List.

And for MAC filtering, you have "how to" from tp-link - official website:

How to configure Wireless MAC address filter on wireless router?


Will "protecting" my certificate require me to enter a password every time I sign an email?

I ended up calling their customer support and got the following answers:

The password needs to be entered the first time an email is sent signed after Outlook opens. Outlook caches the password, so that if a password is associated with the certificate then it only needs to be entered once per session. Whenever Outlook is restarted then the first email sent will require entry of the password.
Without the password a person could potentially copy the certificate off the computer and use it freely to impersonate me.


Why don't very many HTTPS websites supply ownership information in their certs?

Ownership information requires an actual human to look at documentation submitted and verify that it's correct; you can't automate verifying a human-level concept like ownership. If a certificate needs a human to look at and manually approve it, that costs money. Since ownership information isn't something that's very visible to users except for EV certs, and most users don't care almost all of the time, there's no reason to spend the extra money for an ownership-verifying certificate.

(edit: It's not enough for the site to just put it in a cert: for ownership verification to be done in the cert, the CA has to verify the ownership themselves; no CA is willing to sign something claiming to be a person or company unless they verify that that's actually true).


Yes, you can use a master key to generate what is called a "keystream" the size of the plaintext, and XOR it with the plaintext to encrypt it.  This is what we call a stream cipher, and examples are RC4 and Salsa20.

No, this does not provide perfect security.  Claude Shannon demonstrated in 1949 that you cannot have information theoretic perfect secrecy without a random key the same length as the plaintext.  (As many possible keys in the keyspace as plaintexts in the message space.)   The use of a small key means that there are necessarily fewer keys than plaintexts, and expanding them to the length of the message using a pseudo-random generator does not change this.  Use the same key twice, get the same keystream twice.  Because of this, a stream cipher cannot offer the perfect secrecy of a one time pad, where the key is both truly random, and the length of the message.