История изменений
Исправление sanyo1234, (текущая версия) :
Если отпечатков ключей нет на стороне клиента,
Важно не просто наличие отпечатка на клиенте, но и:
1) Нескомпрометированность закрытого ключа (в т.ч. сервера). Иначе неизвестно чей отпечаток вы проверяете, аутентичного хоста или таки как раз MITM хоста.
2) Биндинг отпечатка к хосту, а не просто чтобы отпечаток был в наличии.
то злоумышленник может заставить доверенный CA выпустить новый сертификат.
Предположим, нет такого CA, или вообще нет никакого CA.
А в случае полного отсутствия PKI - просто сгенерировать новую ключевую пару.
Очень любопытно, и как же закрытый ключ клиента подойдет к открытой части пользовательского authorized_keys на левом хосте? Это фантастика? Или как пройдет проверка забинденного на клиенте (к старому ключу оригинального сервера) отпечатка открытого вновь сгенерированного серверного ключа MITM хоста?
Вообще по этому вопросу я не уверен, нужно еще почитать про SSH MITM.
Если атакующий смог считать приватные ключи с файловой системы, то обычно это означает, что он получил root. В таком случае ему и аппаратный ключ не будет помехой - к нему у него тоже будет доступ, и он просто будет его использовать так же, как это бы делал ssh-сервер.
Да фто ви говогите? Это такой новомодний троллинг? А как же многофакторность аппаратных неизвлекаемых ключей?
Предлагаю для начала договориться, какую модель угроз мы рассматриваем. Какие возможности есть у злоумышленника, и что нужно защитить?
Боюсь, что мы с вами замучаемся перечислять эти вектора в 2022 году. Проще пытаться защищаться от всего, так называемый «Zero Trust» ;)
Исправление sanyo1234, :
Если отпечатков ключей нет на стороне клиента,
Важно не просто наличие отпечатка на клиенте, но и:
1) Нескомпрометированность закрытого ключа (в т.ч. сервера). Иначе неизвестно чей отпечаток вы проверяете, аутентичного хоста или таки как раз MITM хоста.
2) Биндинг отпечатка к хосту, а не просто чтобы отпечаток был в наличии.
то злоумышленник может заставить доверенный CA выпустить новый сертификат.
Предположим, нет такого CA, или вообще нет никакого CA.
А в случае полного отсутствия PKI - просто сгенерировать новую ключевую пару.
Очень любопытно, и как же закрытый ключ клиента подойдет к открытой части пользовательского authorized_keys на левом хосте? Это фантастика? Или как пройдет проверка забинденного на клиенте (к старому ключу оригинального сервера) отпечатка открытого вновь сгенерированного серверного ключа MITM хоста?
Если атакующий смог считать приватные ключи с файловой системы, то обычно это означает, что он получил root. В таком случае ему и аппаратный ключ не будет помехой - к нему у него тоже будет доступ, и он просто будет его использовать так же, как это бы делал ssh-сервер.
Да фто ви говогите? Это такой новомодний троллинг? А как же многофакторность аппаратных неизвлекаемых ключей?
Предлагаю для начала договориться, какую модель угроз мы рассматриваем. Какие возможности есть у злоумышленника, и что нужно защитить?
Боюсь, что мы с вами замучаемся перечислять эти вектора в 2022 году. Проще пытаться защищаться от всего, так называемый «Zero Trust» ;)
Исправление sanyo1234, :
Если отпечатков ключей нет на стороне клиента,
Важно не просто наличие отпечатка на клиенте, но и:
1) Нескомпрометированность закрытого ключа (в т.ч. сервера). Иначе неизвестно чей отпечаток вы проверяете, аутентичного хоста или таки как раз MITM хоста.
2) Биндинг отпечатка к хосту, а не просто чтобы отпечаток был в наличии.
то злоумышленник может заставить доверенный CA выпустить новый сертификат.
Предположим, нет такого CA, или вообще нет никакого CA.
А в случае полного отсутствия PKI - просто сгенерировать новую ключевую пару.
Очень любопытно, и как же закрытый ключ клиента подойдет к открытой части пользовательского authorized_keys? Это фантастика? Или как пройдет проверка отпечатка открытого вновь сгенерированного серверного ключа MITM хоста?
Если атакующий смог считать приватные ключи с файловой системы, то обычно это означает, что он получил root. В таком случае ему и аппаратный ключ не будет помехой - к нему у него тоже будет доступ, и он просто будет его использовать так же, как это бы делал ssh-сервер.
Да фто ви говогите? Это такой новомодний троллинг? А как же многофакторность аппаратных неизвлекаемых ключей?
Предлагаю для начала договориться, какую модель угроз мы рассматриваем. Какие возможности есть у злоумышленника, и что нужно защитить?
Боюсь, что мы с вами замучаемся перечислять эти вектора в 2022 году. Проще пытаться защищаться от всего, так называемый «Zero Trust» ;)
Исправление sanyo1234, :
Если отпечатков ключей нет на стороне клиента,
Важно не просто наличия отпечатка на клиенте, но и:
1) Нескомпрометированность закрытого ключа (в т.ч. сервера). Иначе неизвестно чей отпечаток вы проверяете, аутентичного хоста или таки как раз MITM хоста.
2) Биндинг отпечатка к хосту, а не просто чтобы отпечаток был в наличии.
то злоумышленник может заставить доверенный CA выпустить новый сертификат.
Предположим, нет такого CA, или вообще нет никакого CA.
А в случае полного отсутствия PKI - просто сгенерировать новую ключевую пару.
Очень любопытно, и как же закрытый ключ клиента подойдет к открытой части нового сгенерированного ключа MITM хоста? Это фантастика? Или как пройдет проверка отпечатка октрытого вновь сгенерированного серверного ключа MITM хоста?
Если атакующий смог считать приватные ключи с файловой системы, то обычно это означает, что он получил root. В таком случае ему и аппаратный ключ не будет помехой - к нему у него тоже будет доступ, и он просто будет его использовать так же, как это бы делал ssh-сервер.
Да фто ви говогите? Это такой новомодний троллинг? А как же многофакторность аппаратных неизвлекаемых ключей?
Предлагаю для начала договориться, какую модель угроз мы рассматриваем. Какие возможности есть у злоумышленника, и что нужно защитить?
Боюсь, что мы с вами замучаемся перечислять эти вектора в 2022 году. Проще пытаться защищаться от всего, так называемый «Zero Trust» ;)
Исправление sanyo1234, :
Если отпечатков ключей нет на стороне клиента,
Важно не просто наличия отпечатка на клиенте, но и:
1) Нескомпрометированность закрытого ключа (в т.ч. сервера). Иначе неизвестно чей отпечаток вы проверяете, аутентичного хоста или таки как раз MITM хоста.
2) Биндинг отпечатка к хосту, а не просто чтобы отпечаток был в наличии.
то злоумышленник может заставить доверенный CA выпустить новый сертификат.
Предположим, нет такого CA, или вообще нет никакого CA.
А в случае полного отсутствия PKI - просто сгенерировать новую ключевую пару.
Очень любопытно, и как же закрытый ключ клиента подойдет к открытой части нового сгенерированного ключа? Это фантастика?
Если атакующий смог считать приватные ключи с файловой системы, то обычно это означает, что он получил root. В таком случае ему и аппаратный ключ не будет помехой - к нему у него тоже будет доступ, и он просто будет его использовать так же, как это бы делал ssh-сервер.
Да фто ви говогите? Это такой новомодний троллинг? А как же многофакторность аппаратных неизвлекаемых ключей?
Предлагаю для начала договориться, какую модель угроз мы рассматриваем. Какие возможности есть у злоумышленника, и что нужно защитить?
Боюсь, что мы с вами замучаемся перечислять эти вектора в 2022 году. Проще пытаться защищаться от всего, так называемый «Zero Trust» ;)
Исправление sanyo1234, :
Если отпечатков ключей нет на стороне клиента,
Важно не просто наличия отпечатка на клиенте, но и:
1) Нескомпрометированность закрытого ключа (в т.ч. сервера). Иначе неизвестно чей отпечаток вы проверяете, аутентичного хоста или таки как раз MITM хоста.
2) Биндинг отпечатка к хосту, а не просто чтобы отпечаток был в наличии.
то злоумышленник может заставить доверенный CA выпустить новый сертификат.
Предположим нет такого CA или вообще нет никакого CA.
А в случае полного отсутствия PKI - просто сгенерировать новую ключевую пару.
Очень любопытно, и как же закрытый ключ клиента подойдет к открытой части нового сгенерированного ключа? Это фантастика?
Если атакующий смог считать приватные ключи с файловой системы, то обычно это означает, что он получил root. В таком случае ему и аппаратный ключ не будет помехой - к нему у него тоже будет доступ, и он просто будет его использовать так же, как это бы делал ssh-сервер.
Да фто ви говогите? Это такой новомодний троллинг? А как же многофакторность аппаратных неизвлекаемых ключей?
Предлагаю для начала договориться, какую модель угроз мы рассматриваем. Какие возможности есть у злоумышленника, и что нужно защитить?
Боюсь, что мы с вами замучаемся перечислять эти вектора в 2022 году. Проще пытаться защищаться от всего, так называемый «Zero Trust» ;)
Исходная версия sanyo1234, :
Если отпечатков ключей нет на стороне клиента,
Важно не просто наличия отпечатка на клиенте, но и:
1) Нескомпрометированность закрытого ключа. Иначе неизвестно чей отпечаток вы проверяете, аутентичного хоста или таки как раз MITM хоста.
2) Биндинг отпечатка к хосту, а не просто чтобы отпечаток был в наличии.
то злоумышленник может заставить доверенный CA выпустить новый сертификат.
Предположим нет такого CA или вообще нет никакого CA.
А в случае полного отсутствия PKI - просто сгенерировать новую ключевую пару.
Очень любопытно, и как же закрытый ключ клиента подойдет к открытой части нового сгенерированного ключа? Это фантастика?
Если атакующий смог считать приватные ключи с файловой системы, то обычно это означает, что он получил root. В таком случае ему и аппаратный ключ не будет помехой - к нему у него тоже будет доступ, и он просто будет его использовать так же, как это бы делал ssh-сервер.
Да фто ви говогите? Это такой новомодний троллинг? А как же многофакторность аппаратных неизвлекаемых ключей?
Предлагаю для начала договориться, какую модель угроз мы рассматриваем. Какие возможности есть у злоумышленника, и что нужно защитить?
Боюсь, что мы с вами замучаемся перечислять эти вектора в 2022 году. Проще пытаться защищаться от всего, так называемый «Zero Trust» ;)